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Abstract 


This  user  manual  provides  an  overview  of  how  to  use  the  software  developed  to 
support  the  empirical  investigation  of  a  simulated  user  interface  for  an  Advanced 
Integrated  Multi-sensor  Surveillance  (AIMS)  system  (formerly  known  as  the 
Enhanced  Low-Light  Level  Visible  and  Infrared  Surveillance  System  -  ELVISS). 

The  AIMS  system  is  an  electro-optical  imaging  system  being  developed  by  the 
Defence  Research  and  Development  Canada  (DRDC)  -  Valcartier  to  enhance  the 
capability  of  search  and  rescue  (SAR)  crews  to  operate  effectively  at  night  and  in 
degraded  weather  conditions.  In  order  to  ensure  that  a  SAR  operator  would  be  able  to 
use  the  system  effectively  and  with  a  minimal  amount  of  training,  a  prototype  human- 
machine  interface  (HMI)  was  developed  to  evaluate  design  concepts.  The  latest 
development  phase  added  important  tracking  and  motion-related  functionality 
(amongst  other  things)  to  the  system  and  gave  it  a  new  name  AIMSsim. 


Resume 


Le  manuel  de  Tutilisateur  fournit  une  vue  d’ensemble  sur  Tutilisation  du  logiciel 
developpe  pour  appuyer  la  recherche  empirique  d’une  interface-utilisateur  de 
simulation  pour  le  systeme  AIMS  -  systeme  multicapteur  integre  de  pointe  pour  la 
surveillance  (anciennement  connu  sous  Tappellation  ELVISS  -  systeme  perfectionne 
de  surveillance  a  intensification  de  lumiere  visible  et  a  infrarouge).  Le  systeme  AIMS 
est  un  systeme  d’imagerie  electro-optique  mis  au  point  par  Recherche  et 
Developpement  pour  la  defense  Canada  (RDDC)  -  Valcartier  pour  ameliorer  les 
capacites  de  l’equipe  de  recherche  et  sauvetage  (SAR).  Elle  pourra  done  effectuer  ses 
missions  de  fa9on  plus  efficace  dans  Tobscurite  et  dans  de  mauvaises  conditions 
meteorologiques.  Afm  de  s’assurer  que  Toperateur  SAR  est  capable  d’utiliser 
adequatement  le  systeme  et  ce  avec  une  formation  minimale,  un  prototype  d’ interface 
homme-machine  (HMI)  a  ete  elabore  pour  evaluer  les  principes  de  conception.  La 
demiere  phase  d’elaboration  a,  entres  autres,  permis  de  munir  le  systeme  d’une 
importante  fonction  de  localisation  et  d’une  fonction  relative  au  mouvement.  Ces 
ajouts  lui  ont  valu  une  nouvelle  appellation,  AIMSsim. 
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Executive  summary 


Introduction 

This  document  provides  instructions  for  the  installation  and  use  of  software  developed 
to  support  empirical  investigation  of  a  simulated  user  interface  for  an  Advanced 
Integrated  Multi-sensor  Surveillance  (AIMS)  system  (formerly  known  as  the 
Enhanced  Low-Light  Level  Visible  and  Infrared  Surveillance  System  -  ELVISS). 

A  multi-sensor  surveillance  system,  the  Advanced  Integrated  Multi-sensor 
Surveillance  (AIMS)  system,  is  being  developed  to  increase  the  capability  of  Search 
and  Rescue  (SAR)  and  Maritime  patrol.  The  AIMS  system  will  enhance  the  capability 
of  SAR  particularly  at  night  and  in  poor  weather.  Earlier  versions  of  AIMS  were  the 
Airborne  Laser  Based  Enhanced  Detection  and  Observation  System  (ALBEDOS),  and 
the  Enhanced  Low-Light  Level  Visible  and  InfraRed  Surveillance  System  (ELVISS). 
The  AIMS  system  advanced  through  the  integration  of  four  sensors  into  a  single 
gimball.  A  research  platform  that  simulates  use  of  the  airborne  sensor  interface  and 
controls  has  been  developed  at  Defence  Research  and  Development  Canada  (DRDC) 
to  support  evaluation  of  interface  design  concepts  and  to  address  human  performance 
issues  related  to  operating  the  AIMS  and  similar  electro-optical  imaging  systems. 

In  order  to  ensure  that  a  SAR  operator  would  be  able  to  use  the  system  effectively  and 
with  a  minimal  amount  of  training,  a  prototype  human-machine  interface  (HMI)  was 
developed  to  evaluate  design  concepts.  The  VAPS  HMI  prototype  (ELVISS), 
developed  for  the  Silicon  Graphics,  Inc.’s  (SGI)  platform,  provided  a  cost  effective 
method  for  evaluating  the  impact  of  design  characteristics  of  dual  sensor  systems  on 
operator  performance.  However  the  capability  was  limited  and  the  architecture  was  not 
designed  to  support  systematic  investigation  of  the  usefulness  of  the  proposed  system 
under  different  conditions  or  to  manipulate  the  sensor  and  interface  characteristics. 

Results 

The  ELVISS  VAPS  prototype  was  therefore  extensively  enhanced  to  allow  the 
empirical  investigation  of  different  interface  and  sensor  characteristics  on  search  and 
detection  capability  under  different  environmental  conditions.  Included  in  this  upgrade 
was  a  Scenario  Generation  Environment  (SGE)  that  provided  user-friendly  capability 
for  generating  scenarios.  Nonetheless,  despite  the  increased  versatility  of  the  prototype 
the  requirements  of  a  specific  experimental  design  required  that  LUA  scripting 
(www.lua.org)  be  used  to  make  additional  modifications  to  the  software.  While  further 
development  drastically  expanded  the  LUA  scripting  capabilities,  the  SGE  was  not 
similarly  extended  and  some  of  its  scenario-generation  capabilities  became 
incompatible  with  the  prototype.  Thus  LUA  scripting  in  now  the  primary  mode  of 
control  of  the  prototype. 

The  prototype  HMI  was  then  ported  to  run  on  Microsoft  Windows  XP,  and  required 
replacing  the  VAPS  and  SGI  Performer™  with  equivalent  functionality  using  the 
OpenSceneGraph  open  source  graphics  library.  The  robustness  and  traceability  of  the 
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system  were  also  significantly  improved.  The  latest  development  phase  added 
important  tracking  and  motion-related  functionality  (amongst  other  things)  to  this  new 
system  and  gave  it  a  new  name  AIMSsim. 

Significance 

The  experimental  research  platform  at  DRDC  provides  a  means  for  ensuring  that  the 
user  is  an  integral  part  of  the  design  process  and  optimal  design  from  the  user’s 
perspective  is  obtained.  As  technology  advances  and  systems,  like  the  AIMS,  become 
more  complex  for  an  operator  to  use,  user-machine  system  design  becomes  more 
critical  and  challenging.  The  continued  development  and  upgrade  of  the  AIMSsim 
research  platform  provides  the  experimenter  with  an  appropriate  level  of  simulation 
detail  to  conduct  human  peformance  analyses  which  in  turn  delivers  up-to-date 
knowledge  and  advice  on  the  design  of  sensor  surveillance  systems  to  the  military 
stakeholder.  A  System  Manual  (Schoenbaum,  2007a)  describing  the  architecture  and 
capabilities,  and  a  Final  Report  (Schoenbaum,  2007b)  that  summarizes  the  work 
performed  and  makes  recommendation  for  future  work,  are  also  associated  with  this 
document. 
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Introduction 

Le  manuel  foumit  les  instructions  sur  Installation  et  l’utilisation  du  logiciel 
developpe  pour  appuyer  la  recherche  empirique  d’un  interface-utilisateur  de 
simulation  pour  le  systeme  AIMS  -  systeme  multicapteur  integre  de  pointe  pour  la 
surveillance  (anciennement  connu  sous  l’appellation  ELVISS  -  systeme  perfectionne 
de  surveillance  a  intensification  de  lumiere  visible  et  a  infrarouge). 

Systeme  multicapteur  de  surveillance,  le  AIMS  est  en  cours  de  developpement  pour 
ameliorer  les  capacites  de  recherche  et  sauvetage  (SAR)  et  de  la  patrouille  maritime. 

Le  systeme  AIMS  optimisera  les  capacites  de  SAR  plus  particulierement  la  nuit  et  dans 
de  mauvaises  conditions  meteorologiques.  D’autres  versions  du  systeme  AIMS  avaient 
deja  ete  developpees,  soit  le  systeme  laser  aeroporte  perfectionne  de  detection  et 
d’observation  (ALBEDOS)  et  le  systeme  perfectionne  de  surveillance  a  intensification 
de  lumiere  visible  et  a  infrarouge  (ELVISS).  Le  systeme  AIMS  est  superieur  a  ses 
predecesseurs  grace  a  L integration  de  quatre  capteurs  dans  un  seul  cardan.  Une 
plateforme  de  recherche  qui  simule  l’utilisation  et  la  commande  de  l’interface  de 
capteur  aeroporte  a  ete  elaboree  par  Recherche  et  Developpement  pour  la  defense 
Canada  (RDDC)  afin  d’appuyer  L  evaluation  des  principes  de  conception  et  pour 
aborder  les  questions  relatives  au  rendement  humain  lie  a  l’utilisation  du  systeme 
AIMS  et  de  systemes  d’imagerie  electro-optique  semblables. 

Afin  de  s’assurer  que  l’operateur  SAR  est  capable  d’utiliser  adequatement  le  systeme, 
et  ce  avec  une  formation  minimale,  un  prototype  d’interface  homme-machine  (HMI)  a 
ete  elabore  pour  evaluer  les  principes  de  conception.  Le  prototype  VAPS  HMI 
(ELVISS),  developpe  pour  la  plateforme  de  Silicon  Graphics,  Inc.  (SGI),  a  foumi  une 
methode  economique  pour  evaluer  l’impact  sur  le  rendement  de  l’operateur  des 
caracteristiques  de  conception  des  systemes  de  capteurs  jumeles.  Le  systeme  a 
demontre  que  ses  capacites  etaient  limitees  et  que  son  architecture  n’avait  pas  ete 
confue  pour  permettre  une  recherche  systematique  de  l’utilite  du  systeme  propose  dans 
differentes  conditions  ou  pour  manipuler  les  caracteristiques  des  capteurs  et  de 
L  interface. 

Resultats 

Le  prototype  ELVISS  VAPS  a  done  ete  grandement  ameliore  pour  permettre  la 
recherche  experimentale  sur  des  interfaces  differentes  et  des  caracteristiques  de 
capteurs  pour  la  recherche  et  la  detection  dans  diverses  conditions  environnementales. 
Cette  version  amelioree  incluait  egalement  un  environnement  de  generation  de 
scenarios  (Scenario  Generation  Environment  [SGE])  qui  foumissait  une  capacite 
conviviale  pour  generer  des  scenarios.  Finalement,  malgre  la  polyvalence  amelioree  du 
prototype,  les  exigences  d’une  conception  experimentale  specifique  demandaient 
qu’un  script  LUA  (www.lua.org)  soit  utilise  pour  apporter  des  modifications 
supplementaires  au  logiciel.  Tandis  que  des  nouveaux  progres  elargissaient  les 
capacites  de  script  LUA,  le  SGE  n’evoluait  pas  de  la  meme  fa5on  et  quelques-unes  de 
ces  capacites  de  scenarisation  sont  meme  devenues  incompatibles  avec  le  prototype. 
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C’est  pourquoi  le  script  LUA  est  maintenant  le  principal  mode  de  controle  du 
prototype. 

Le  prototype  HMI  a  alors  ete  adapte  pour  fonctionner  avec  Microsoft  Windows  XP,  et 
a  demande  le  remplacement  de  VAPS  (Virtual  Applications  Builder)  et  de  SGI 
Performer™  par  une  fonctionnalite  equivalente  utilisant  la  graphitheque  de  source 
ouverte  OpenSceneGraph.  La  robustesse  et  la  tragabilite  du  systeme  ont  egalement  ete 
ameliorees  de  fag  on  significative.  Le  derniere  phase  de  developpement  a,  entres  autres, 
munie  le  systeme  d’une  importante  fonction  de  localisation  et  d’une  fonction  relative 
au  mouvement.  Ces  ajouts  lui  ont  valu  une  nouvelle  appellation,  AIMSsim. 

Portee 

La  plateforme  de  recherche  experimental  a  RDDC  a  foumi  des  moyens  pour  s’ assurer 
que  l’utilisateur  fait  partie  du  processus  de  conception  et  que  la  perspective  de  ce 
dernier  sur  la  conception  optimale  est  connue.  Tout  comme  la  technologie,  les 
systemes  comme  AIMS  se  perfectionnent  et  deviennent  de  plus  en  plus  complexes  a 
utiliser  pour  un  operateur;  la  conception  du  systeme  utilisateur-machine  devient  de 
plus  en  plus  important  et  impose  de  nouveaux  defis.  Le  developpement  continu  et  la 
mise  a  niveau  de  la  plateforme  de  recherche  AIMSsim  procurent  a  Texperimentateur 
assez  de  detail  sur  la  simulation  pour  effectuer  des  analyses  sur  le  rendement  humain 
qui,  a  leurs  tours,  foumissent  aux  intervenants  militaires  une  connaissance  actuelle  et 
des  recommandations  sur  la  conception  de  systemes  de  capteurs  de  surveillance.  Un 
manuel  de  systeme  (Schoenbaum,  2007a)  decrivant  Tarchitecture  et  les  capacites  du 
systeme  et  un  rapport  final  (Schoenbaum,  2007b)  resumant  les  travaux  effectues  et 
faisant  des  recommandations  pour  de  futures  recherches,  sont  egalement  lies  au 
present  document. 
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Foreword 


The  first  version  of  this  document  was  written  by  the  HFE  Group  in  Ottawa.  Since  then,  many 
contributors  have  modified  and  added  to  its  content.  This  version  of  the  document  includes 
new  sections  and  content  that  better  reflects  the  current  operation  of  the  AIMSsim  FIMI 
Prototype.  The  FIFE  group  is  no  longer  responsible  for  the  content  of  this  document,  and  it  did 
not  participate  in  the  latest  modifications. 
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1  Introduction 


1.1  General 

The  DRDC  Valcartier  has  been  developing  a  flyable  prototype  of  an  Advanced 
Integrated  Multi-sensor  Surveillance  (AIMS)  system  (formerly  known  as  the 
Enhanced  Low-Light-Level  Visible  and  Infrared  Surveillance  System  -  ELVISS). 
DRDC  has  been  contracting  out  the  development,  and  subsequent  enhancement  of  the 
capabilities,  of  the  AIMS  human-machine  interface  (HMI)  prototype,  to  allow  the 
empirical  investigation  of  different  interface  and  sensor  characteristics  on  search  and 
detection  capability  under  different  simulated  environmental  conditions. 

1.2  Background 

DND  has  identified  a  requirement  to  enhance  the  capabilities  of  Search  And  Rescue 
(SAR)  operators  to  conduct  operations  at  night  and  under  degraded  weather 
conditions.  To  this  end,  the  Defence  Research  Establishment  Valcartier  (DREV)  is 
developing  a  multi-sensor  system  composed  of  an  Active  Imaging  System  (the 
Airborne  Laser-Based  Enhanced  Detection  and  Observation  System  —  ALBEDOS) 
and  a  thermal  Infrared  (IR)  imaging  system.  By  coordinating  the  use  of  a  pulsed  laser 
illuminator  and  AGTV  camera,  the  AGTV  component  of  AIMS  provides  effective 
imaging  in  the  absence  of  ambient  light.  In  addition,  the  active  range  gate  allows  the 
AGTV  system  to  penetrate  meteorological  phenomena  such  as  fog,  snow  and  rain 
much  more  effectively  than  a  FLIR  camera.  The  FLIR  camera  is  a  passive  thermal 
imaging  system  that  produces  an  image  based  on  temperature  variation  by  detecting 
mid-infrared  and  far-infrared  radiation.  Both  sensors  are  bore  sighted  and  are 
packaged  in  a  gimballed  “ball”  that  is  mounted  on  the  exterior  of  an  aircraft  or  vehicle. 
The  use  of  gyros  inside  the  ball  allows  the  camera  within  to  maintain  its  orientation  in 
the  Earth  frame  of  reference,  without  being  affected  by  roll,  pitch  and  yaw  changes  in 
the  supporting  aircraft  or  vehicle. 

In  order  to  ensure  that  a  SAR  operator  would  be  able  to  use  the  system  effectively  and 
with  a  minimal  amount  of  training,  a  prototype  HMI  was  developed  to  evaluate  design 
concepts.  The  VAPS  HMI  prototype  (ELVISS),  developed  for  the  Silicon  Graphics, 
Inc.’s  (SGI)  platform,  provided  a  cost  effective  method  for  evaluating  the  impact  of 
design  characteristics  of  dual  sensor  systems  on  operator  performance.  However  the 
capability  was  limited  and  the  architecture  was  not  designed  to  support  systematic 
investigation  of  the  usefulness  of  the  proposed  system  under  different  conditions  or  to 
manipulate  the  sensor  and  interface  characteristics. 

The  ELVISS  VAPS  prototype  was  therefore  extensively  enhanced  to  allow  the 
empirical  investigation  of  different  interface  and  sensor  characteristics  on  search  and 
detection  capability  under  different  environmental  conditions.  Included  in  this  upgrade 
was  a  Scenario  Generation  Environment  (SGE)  that  provided  user-friendly  capability 
for  generating  scenarios.  Nonetheless,  despite  the  increased  versatility  of  the  prototype 
the  requirements  of  a  specific  experimental  design  required  that  LUA  scripting  be  used 
to  make  additional  modifications  to  the  software.  While  further  development 
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drastically  expanded  the  LUA  scripting  capabilities,  the  SGE  was  not  similarly 
extended  and  some  of  its  scenario-generation  capabilities  became  incompatible  with 
the  prototype.  Thus  LUA  scripting  in  now  the  primary  mode  of  control  of  the 
prototype. 

The  prototype  HMI  was  then  ported  to  run  on  Microsoft  Windows  XP,  and  required 
replacing  the  VAPS  and  SGI  Performer™  with  equivalent  functionality  using  the 
OpenSceneGraph  open  source  graphics  library.  The  robustness  and  traceability  of  the 
system  were  also  significantly  improved.  The  latest  development  phase  added 
important  tracking  and  motion-related  functionality  (amongst  other  things)  to  this  new 
system  and  gave  it  a  new  name  AIMSsim. 

Aim 

The  aim  of  this  report  is  to  provide  instructions  for  installation  and  use  of  software 
developed  to  support  empirical  investigation  of  a  simulated  user  interface  for  the 
AIMS  Human  Machine  Interface  (HMI). 

Objectives 

The  specific  objectives  of  this  report  are  to: 

a.  Describe  the  process  of  installing  AIMSsim; 

b.  Provide  instructions  on  the  use  of  AIMSsim  software 

Report  Outline 

The  report  is  structured  as  follows: 

1.  Section  One  describes  the  background,  aim  and  scope  of  this  document; 

2.  Section  Two  explains  the  process  of  installing  AIMSsim; 

3.  Section  Three  documents  the  experiment  development  and  execution  process 
(EDEP)  to  follow  when  using  AIMSsim; 

4.  Section  Four  documents  the  use  of  the  main  component  of  AIMSsim;  and 

5.  Various  annexes  document  the  scripting  functions  and  predefined  variables, 
predefined  system  events  and  messages,  target  object  types,  OpenFlight  file 
conversion  to  other  formats  via  OpenSceneGraph,  and  the  AIMS  Scenario 
Generation  Environment  (SGE). 
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2  Installation 


2.1  General 

The  following  subsections  describe  the  process  of  installing  the  AIMSsim  components 
and  supporting  software.  The  instructions  in  this  section  assume  a  basic  working 
knowledge  of  the  Microsoft  Windows  operating  system  and  understanding  of  the 
AIMSsim  System  Manual,  especially  with  regards  to  simControl  and  simDisplay.  The 
instructions  also  assume  that  you  have  logged  onto  the  system  and  have  read  and  write 
privileges  for  the  target  directory  into  which  you  intend  to  install  the  AIMSsim 
software. 

2.2  Before  You  Begin 

Before  you  begin  installing  AIMSsim: 

•  Ensure  that  the  system  requirements  defined  in  AIMSsim  System  Manual  have 
been  met. 

•  Ensure  that  you  have  adequate  permissions  to  write  data  to  the  target  directories 
into  which  you  intend  to  install  the  software. 

•  Ensure  that  you  have  the  required  amount  of  hard-disk  space  before  installing,  i.e. 
approximately  1G,  due  to  the  large  size  of  the  included  terrain  databases. 

2.3  Installing  the  AIMSsim  Software 

1.  Extract  the  contents  of  the  AIMS_SW_*.zip  file  you  obtained  to  a  location  of  your 
choice.  This  will  create  a  folder  containing:  the  binaries  for  the  HMI  prototype  and 
SGE  software  with  supporting  DLLs,  subfolders  for  some  experimentation  scripts, 
and  a  copy  of  the  System  and  User  manuals.  We  will  refer  to  this  folder  as 

AIMSHOME. 

2.  (Optional)  Create  a  shortcut  to  the  SGE  executable  on  your  desktop 

3.  Extract  the  contents  of  the  AIMS_DB_*.zip  file  you  obtained  to  a  location  of  your 
choice.  This  is  the  visualization  database  (referred  to  in  this  document  as 
AIMSDB). 

4.  Connect  the  FlyPanel  to  the  computer,  according  to  the  FlyPanel  manual.  This 
basically  consists  in  connecting  one  FlyPanel  cable  to  one  of  your  PC’s  serial  ports 
(the  same  as  specified  by  FB  PORT  below),  and  the  FlyPanel’ s  power  cable  to  a 
power  supply. 

5.  Define  the  following  AIMSsim  environment  variables  (see  Figure  1): 

a.  AIMS  DATA  (required):  points  to  the  AIMS  DB  folder. 

b.  AIMS  DPI  (required):  a  space-separated  pair  of  values  that  define  the 
horizontal  and  vertical  dots-per-inch  of  your  monitor.  This  is  necessary  for 
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an  accurate  scaling  of  the  Moving  Map  Display.  E.g.  a  21”  monitor  has  a 
screen  15.75”  x  11.5”.  At  a  resolution  of  1600  by  1200,  this  would  imply 
an  AIMS  DPI  equal  to  “101.587  104.348”. 

c.  AIMS  SCEN  (required  only  if  you  want  to  use  the  SGE):  points  to  a  folder 
of  your  choice,  where  the  SGE  will  save  and  load  project  files.  Note  that 
you  can  easily  override  this  from  the  SGE  through  its  File  Browser. 

d.  FB  PORT  (required  only  if  default  inadequate):  defaults  to  “COM1”;  set  it 
to  some  other  appropriate  value  (e.g.  “COM2”  or  “COM3”)  depending  on 
which  serial  port  your  FlyPanel  is  connected  to. 


Figure  1:  AIMS  environment  variables  defined 
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3  Experiment  Development  and  Execution  Process 


The  instructions  in  this  section  assume  a  basic  understanding  of  the  AIMSsim  System 
Manual,  especially  with  regards  to  simControl  and  simDisplay.  This  section  also 
requires  a  basic  understanding  of  scripting.  Knowledge  of  LUA  scripting  is  not 
necessary  but  will  be  useful. 

AIMSsim  represents  virtual  prototypes  of  proposed  AIMS  system  interfaces.  A  virtual 
interface  allows  you  to  test  and  evaluate  the  impact  of  different  interface  and  sensor 
characteristics  on  search  and  detection  tasks  by  simulating,  in  real  time,  “experiments” 
(also  known  as  “scenarios”)  described  by  scenario  text  files,  and  by  allowing  you  to 
collect  data  on  how  well  the  system  was  operated  in  accomplishing  the  goals  set  out  by 
the  scenario. 

Usage  of  AIMSsim  involves  several  steps: 

1.  Develop  experiment: 

a.  Design  your  experiment  (conceptually) 

b.  Convert  it  to  a  Finite  State  Machine  (FSM),  diagrammatic  ally 

c.  Determine  which  scripts  are  available  for  re-use  by  looking  at  previous 
experiments,  and  the  LuaUtils  folder  in  AIMSHOME 

d.  Create  a  directory,  in  AIMS  HOME,  for  your  new  experiment 

e.  Create  the  LUA  initialization  script  for  your  experiment,  or  copy  it  from 
another  experiment  and  edit  it 

f.  Create  the  remaining  LUA  scripts  for  the  FSM  and  other  tasks 
(designation,  etc),  or  copy  from  existing  ones  and  edit 

g.  Run  simControl  to  test  and  debug  the  experiment;  this  involves  looking  at 
the  visual  display  for  proper  sequence  of  screens,  and  proper  changes  of 
states  and  settings;  as  well  as  looking  for  any  messages  in  the  DOS  shell 
or  in  the  log  files  sim  * _Iog.txt  that  get  created  by  each  process  in 
AIMS  HOME,  and  looking  at  any  collected  data  for  correctness 

h.  Edit  the  experiment’s  LUA  scripts  until  experiment  works  as  required 

2.  Execute  experiment: 

a.  Run  simControl  to  execute  the  experiment  and  collect  data 

b.  Analyze  data 

Steps  1  d  to  If  result  in  a  set  of  LUA  scripts,  referred  to  as  your  Experiment  Simulation 
(ExS)  Scripts. 

In  older  generations  of  AIMSsim,  steps  Id  to  If  did  not  involve  LUA  scripts  but  plain 
text  files  with  value  settings.  These  value  files  could  be  created  from  the  AIMS 
Scenario  Generation  Environment  (SGE)  and  read  by  AIMSsim.  Since  the  scripting 
capabilities  were  added  to  AIMSsim,  only  the  flight  plan  and  the  targets  files  created 
by  the  SGE  can  be  read  into  simControl.  Settings  saved  by  the  SGE  in  the  SGE  project 
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configuration  file  (such  as  environmental  conditions  etc  —  see  the  AIMSsim  System 
Manual)  can  no  longer  be  read  by  simControl.  Due  to  the  loose  coupling  between  the 
simControl  and  the  SGE,  use  of  the  SGE  is  described  in  detail  in  Annex  E. 

3.1  Experiment  Simulation  (ExS)  scripts 

LUA  scripting  was  added  to  the  AIMS  HMI  Prototype  as  the  means  of  describing 
experiments.  LUA  is  a  relatively  simple  language  that  is  interpreted  at  run  time  and 
uses  a  C  like  syntax.  For  official  information  about  LUA,  visit  www.lua.org. 

While  LUA  is  easy  to  use,  it  is  at  the  same  time  a  very  powerful  language.  One  major 
departure  from  C  and  many  other  languages  is  that  variables  do  not  have  to  be 
declared  before  they  are  used.  This  eases  development,  but  makes  debugging  a  little 
more  difficult.  Be  sure  that  you  are  spelling  variables  correctly.  Also,  it  is  suggested 
that  each  script  contain  a  comment  in  the  first  few  lines  of  the  script,  describing  all 
global  variables  that  are  assumed  to  exist  when  the  script  is  called. 

One  LUA  script  is  required  to  initialize  the  AIMSsim  system,  and  one  LUA  script  is 
possible  per  state  transition  in  the  FSM. 

All  standard  LUA  library  functions  are  available  for  use  in  your  experiment  scripts.  In 
addition  to  these  standard  functions,  there  are  a  large  number  of  AIMSsim  functions 
and  settings  that  have  been  made  available  through  the  scripting  interface.  These  are 
the  functions  that  will  be  the  most  useful  for  implementing  experiments.  See  Annex  A 
for  a  table  of  all  exported  AIMSsim  functions  available  to  your  scripts. 

In  addition,  there  are  a  few  AIMSsim  facilities  that  have  been  exposed  to  aid  in 
experiment  implementation: 

•  User  Timer:  a  timer  exists  to  allow  response  times  to  be  captured  through  scripts. 
It  is  up  to  the  experimenter  to  ensure  that  this  timer  is  reset  and  read  at  the 
appropriate  time,  via  the  ResetUserTimerQ  and  GetUserElapsedTimeQ  functions. 
Note  that  LUA  provides  timing  functions  natively,  however  they  provide  only  1 
second  resolution. 

•  User  Variables  (deprecated):  they  exist  in  3  forms,  integers,  integer  arrays,  and 
float  arrays.  User  variables  are  uniquely  identified  by  their  names,  and  are 
created  as  the  user  sets  them.  They  were  originally  provided  as  a  safe  way  to 
share  data  between  scripts,  as  they  differ  from  native  LUA  global  variables  in  two 
ways: 

o  How  they  are  accessed:  user  variables  are  accessed  via  the  Set*()  and  Get*() 
AIMSsim  functions  as  quoted  arguments,  whereas  LUA  variables  appear 
directly  LUA  script  expressions,  unquoted. 

--  Initialization  script 

setlnt ( "hello" ,  3);  #  User  variable  named  "hello" 

--  Some  other  script 

hello  =  Getlnt ("hello") ;  #  Get  its  value,  put  in  LUA  variable 

goodbye  =  hello  +  2;  #  change  LUA  variable 

setlnt ("hello",  goodbye);  #  commit  change  to  User  variable 
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o  Behavior  when  undefined:  If  a  script  tries  to  access  an  undefined  user 
variable,  it  will  get  0,  whereas  an  undefined  LUA  variable  is  nil  and  will 
cause  an  error  message  to  be  printed  to  the  shell  window. 

This  feature  has  been  deprecated  because  it  bypasses  one  of  the  fundamental 
validation  mechanisms  available  in  LUA:  exceptions.  If  a  script  attempts  to  use  a 
LUA  native  variable  that  is  undefined,  the  LUA  interpreter  will  raise  an 
exception,  which  will  appear  immediately  in  the  simControl_log.txt  file.  An 
undefined  user  variable  appears  as  a  zero  in  your  scripts,  which  will  rarely  cause 
any  errors,  let  alone  a  meaningful  error  message  identifying  file  and  line  where 
the  error  occurred;  if  you  are  lucky,  you  may  eventually  notice  unexpected 
behavior,  but  this  will  often  not  be  the  case,  and  is  much  more  difficult  to 
troubleshoot. 

LUA  variables  are  by  default  global.  Variables  declared  in  one  script  are  available 
in  other  scripts  run  during  the  experiment  (because  a  single  LUA  virtual  machine 
is  used).  The  use  of  the  “local”  qualifier  on  variables  is  encouraged  as  a 
mechanism  to  minimize  the  number  of  global  variables  that  exist  during  an 
experiment: 


local  a  =  1 
local  b  =  a+2 
print  (b) 

This  helps  decrease  the  likelihood  that  a  variable  meant  only  for  local  use  in  a 
script  has  the  same  name  as  one  of  your  “undefined”  global  variables. 

•  Experiment  execution  trace:  every  call  to  exported  functions  and  every  change 
to  exported  settings  can  be  logged  so  as  to  get  a  “trace”  (in  programmer  parlance) 
of  the  script  execution.  Each  trace  message  says  what  has  been  done,  what  new 
value  has  been  set  etc.  Very  useful  while  developing  an  experiment. 

Some  typical  tasks  done  in  an  initialization  script: 

•  Set  up  AIMSsim  configuration  variables  (FOV,  map  mode,  etc) 

•  Set  up  some  global  run-time  constants  used  by  your  experiment 

•  Define  terrain  database  to  use 

•  Define  path  plans 

•  Define  targets  and  each  one’s  attributes 

•  Add  path  plans  to  targets  and/or  aircraft 

•  Define  FSM 

•  Define  run-timed  and  flight-timed  transition  events  (e.g.,  to  turn  off  the  MMD 
at  specific  times  of  the  run  or  of  the  flight) 

•  Define  scripts  to  be  run  at  every  time  step  (so-called  “periodic”  scripts) 

•  Schedule  an  event  to  transition  away  from  the  “INIT”  state  after  initialization 
script  has  completed 


The  following  box  shows  an  example  AIMSsim  initialization  LUA  script,  performing 
several  of  the  above  tasks.  Some  of  these  will  explained  in  later  sections. 
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Trace (1) 

function  log(logFile,  msg) 

local  curout  =  io. output  () 
io . output  (logFile) 
io .write (msg,  "\n") 
io . output  (curout ) 

end 

do file ( " Designation/ ini tWor Id. lua" ) 
dof ile ( "Designation/initFSM. lua" ) 

--  use  the  look-at  algorithm  for  autotracking 
autoTrackByLookat  =  true 
autoTrackDesignatedTarget  =  true 

userResponse2Change  =  { }  —  empty  table  to  store  results 


--  Info  for  saving  field  of  view  measures 
fovScript  =  "Designation/outFOV. lua" 
fovFName  =  "Designation/results/fov. txt " 
fovFile  =  io . open ( fovFName ,  "w") 
if  fovFile  then 

AddPeriodicScript (fovScript) 

else 

print ( "Could  not  open  '"..fovFName.."',  can't  save  FOV") 

end 

--  Open  a  file  to  save  tracking  measures;  will  use  stdout  if  for  some 
—  reason  file  can't  be  opened. 

trackingFName  =  "Designation/results/tracking . txt" 
trackingFile  =  io . open (trackingFName, "w" ) 
if  not  trackingFile  then 

print  ("Can't  open  file  '"..trackingFName.."',  can't  save  tracking  measures,  using  stdout 
instead" ) 
end 

--  Define  the  "save"  function  to  save  tracking  measurements,  needed  by  tracking  script 
function  saveTrackingMeasure (targetDistance ,  targetRelSpeed,  targetLOSH,  targetLOSP) 
msg  =  string . format ("%. 2 f  %.2f  %.2f  %.2f  %.2f\n",  GetRuntime ( ) , 
targetDistance,  targetRelSpeed,  targetLOSH,  targetLOSP) 
if  trackingFile  then 

trackingFile :write (msg) 

else 

print (msg) 

end 

end 

--  and  the  comment  function  for  outputting  comments  to  file 
function  commentTrackingMeasure (comment) 
if  trackingFile  then 

trackingFile :write (comment) 

end 

end 


--  We're  done,  notify  system  that  we  can  switch  to  next  state 
GenerateEvent ( "EVENT : initDone" ) 


Figure  2.  Example  AIMSsim  ExS  initialization  script 
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3.2  Programmable  Finite  State  Machine 

The  flow  of  an  experiment  can  described  using  a  finite  state  machine  (FSM).  In  order 
to  provide  the  capability  to  run  the  largest  number  of  possible  experiments,  the 
scriptable  architecture  allows  the  state  machine  that  describes  an  experiment  to  be  set 
at  initialization  time  through  scripts.  This  allows  for  any  ordering  of  screens  and 
behavior  to  be  created.  AIMSsim  should  be  able  to  behave  according  to  any  desired 
experimental  flow  using  the  facilities  provided.  It  should  be  noted,  however,  that  care 
must  be  taken  in  describing  the  FSM  of  an  experiment,  since  there  is  no  facility  to 
ensure  that  the  FSM  described  makes  sense. 

A  FSM  can  be  viewed  as  a  graph  with  the  nodes  representing  states,  and  the  arcs 
representing  state  transitions  (see  the  System  Manual).  By  describing  all  the 
transitions,  the  FSM  can  be  fully  described.  Transitions  are  described  using  four 
fields:  the  current  state,  the  next  state,  the  triggering  event,  and  the  action  to  take.  This 
is  done  via  the  exported  AddTransitionQ  function,  normally  during  the  initialization 
script.  Only  one  transition  <state,  event>  pair  is  possible. 

The  states  can  be  named  as  desired  by  the  experimenter  with  the  following  two 
exceptions:  the  initial  state  is  always  called  “STATETNIT”,  and  the  final  state  is 
always  called  “STATE:EXIT”.  In  addition,  all  states  must  start  with  the  name 
“STATE:”.  It  is  up  to  the  experimenter  to  provide  a  transition  from  the  “INIT”  state.  A 
good  way  of  doing  this  is  by  having  the  last  line  of  the  initialization  script  call  the 
GenerateEventO  function  with  the  proper  event  name  defined  in  the  experiment’s 
FSM.  It  is  also  up  to  the  experimenter  to  provide  for  a  transition  into  the  “EXIT”  state 
that  will  cause  the  system  to  exit. 

State  transitions  within  your  experiment’s  FSM  are  executed  in  response  to  events. 
Each  transition  causes  a  corresponding  LUA  script  to  be  run,  if  one  was  specified  in 
the  initialization  script.  There  are  a  number  of  ways  for  events  to  be  triggered: 

1 .  System  events  are  automatically  triggered  by  the  system  under  specific 
conditions.  These  events  have  set  names  and  are  described  in  Annex  B.  E.g., 
when  the  exit  screen  is  shown  with  the  exit  button,  an 

EVENT:EXIT_PRESSED  event  is  generated  when  the  user  presses  the  button. 

2.  Timed  events  can  be  added  using  the  AddTimedEventQ  and 

A d d h 7 igh t T in i ed E ven t{ )  functions.  Timed  event  names  are  chosen  by  the 
experimenter.  A  timed  event  occurs  at  a  specific  runtime  or  flight  time,  and 
causes  an  event  to  be  generated. 

3.  Generic  events  can  be  generated  within  scripts  using  the  GenerateEventO 
function.  Generic  events  can  be  named  as  desired  by  the  experimenter,  except 
for  the  constraint  that  all  events  must  start  with  the  word  “EVENT:”. 

The  following  table  shows  an  example  experiment,  and  associated  states  and  events. 
System  State  names  and  System  Event  names  are  in  italics,  all  others  are  arbitrary 
names  and  specific  to  this  simplified  example: 
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Table  1.  Example  AIMSsim  experiment 


Experiment  stage 

State  Name 

LUA  script 
to  execute 
on  entry  to 
state 

Transition  event 

1. 

Initialize 

STATE  :INIT 

initialization 

script 

EVENT  rDONEINIT 

2. 

Show  the  startup  screen,  wait 
for  setup  complete:  operator 
ready,  database  loaded,  etc. 

STATErSHOWSTART 

toStartup.lua 

Press  “Start” 
(ENENE:START  PRES 
SED) 

3. 

Show  operator  interface,  but  no 
operation  allowed;  the  aircraft 
flies  along  prescribed  flight 
path;  wait  for  timed  event  or 
end  of  flight  path 

STATErFLYING 

toFlying.lua 

Timed  event 
(EVENT:  SEARCH  TI 
ME) 

or 

flight  path  done 
(EVENT : END  OF _FP) 

4. 

At  predefined  points  in  time, 
freeze  aircraft,  hide  map,  add  a 
target  to  landscape,  and  allow 
operator  to  use  joystick 
controls  to  move  sensor 
cameras  until  target  found;  wait 
for  them  to  press  "button  9"  on 
their  control 

STATE:SEARCHING 

toSearching.lua 

Button  9  clicked 
(EVENFB9  PRESSED 
) 

5. 

Take  a  snapshot  of  current 
camera  view  and  save  it 

STATErCAPTURE  IMA 

GE 

toCapture.lua 

Image  saved 

( EVENT: IMAGE  CAPT 

URED) 

6. 

Resume  flight  path  and 
reactivate  map;  ie  aircraft  starts 
moving  again,  but  operator 
can't  control  anything;  prepare 
for  next  target  with  timed 
event, 

OR  (item  #8) 

STATErFLYING 

toFlying.lua 

Timed  event 
(EVENT :  SE ARC  H  TI 
ME) 

7. 

No  more  targets:  continue 
flying  until  flight  path 
completed 

Flight  path  completed 
(EVENT : END  OF _FP) 

8. 

Flight  path  completed.  Save 
data,  close  files,  etc. 

STATErEXITING 

toExit.lua 

9. 

Exit  program 

STATE:  EXIT 

The  corresponding  finite  state  diagram  would  be  as  shown  in  Figure  3. 
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Figure  3.  Possible  FSM  for  example  experiment 


The  LUA  script  stateMachine  .  lua,  executed  by  the  example  initialization  script 
in 

Figure  2,  is  shown  in  Figure  4.  This  shows  how  the  recording  of  a  specific  response  by 
the  user  (LOC#_PRESSED),  one  of  8  choices,  uses  a  transition  script  specific  to  the 
response.  It  is  up  to  the  script  to  make  sure  that  the  system  returns  to  the  FLYING  state 
(e.g.,  by  itself  calling  dofile  ("toFlying.  lua") ;  however  the  FSM  could  be 
modified  to  use  an  event  instead). 


AddTransition ( ” STATE : INIT" ,  ' 

STATE: STARTUP" , 

"EVENT: DONE  INIT", 

' . /SC /generic /toS tar tup . lua" ) 

AddTransition ("STATE: STARTUP' 

,"  STATE: FLYING", 

"EVENT: START  PRESSED" 

/SC /generic /toFlying . lua" ) 

AddTransition ( " STATE : FLYING" , 

"  STATE : EXITS"  , 

"EVENT: END  OF  FP" , 

' . /SC/generic/toExit . lua" ) 

AddTransition ( " STATE : FLYING" , 

"  STATE : SEARCH" , 

"EVENT: SEARCH  TIME", 

' . /SC/generic/toSearch. lua") 

AddTransition ("STATE: SEARCH", 

"  STATE : CAPTURE", 

"EVENT :B9  PRESSED", 

' . /SC/generic/toCapture . lua" ) 

AddTransition ("STATE: CAPTURE' 

, "FLYING" , 

"EVENT: IMAGE  CAPTURED 

' ,  " . /SC/generic/toQuestion . lua" ) 

AddTransition ("STATE : EXITS" , ' 

STATE: EXIT", "EVENT : EXIT_PRESSED" ,  "") 

Figure  4.  Example  FSM 


Note  however  that  for  a  non-trivial  experiment,  there  can  be  many  different  FSM 
representations.  Your  choice  should  be  based  on  clarity  and  modularity,  rather  than 
brevity  or  ease.  The  extra  effort  will  pay  off  when  debugging  and  extending  your 
experiment. 
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The  following  list  outlines  some  of  the  tasks  that  could  take  place  in  the  above 
example. 


•  toStartup.lua: 

o  tell  simDisplay  to  show  startup  screen 

o  create  “target  event  number”  to  count  how  many  targets  have  been  found 

•  toFlying.lua: 

o  reset  user  time  to  0  every  time  entering  this  state  (as  if  each  waypoint  was 
the  beginning  of  the  simulation) 

o  tell  simDisplay  to  update  the  display,  because  targets  are  removed  in 
other  scripts  (like  toCapture.lua) 

o  disable  joystick  input  and  resume  the  aircraft  motion  along  flight  path 
o  set  sensor  heading  since  defaults  to  0  pitch,  or  if  not  first  time  run, 
operator  has  likely  changed  it  while  search  for  target 
o  start  updating  sensor  heading  periodically  so  it  follows  aircraft  direction 
o  increase  "target  event"  number 
o  tell  simDisplay  to  switch  to  "operational"  screen 

•  toSearch.lua: 

o  clear  the  targets  set  (removes  all  targets  from  display) 
o  stop  all  ongoing  data  collection 
o  enable  joystick  input 
o  pause  flight  path 
o  play  sound  (e.g.  to  alert  operator) 

o  get  desired  heading  and  pitch  of  target,  using  target  and  bearing  table 
o  add  a  target  there  and  tell  simDisplay  to  update  its  scene  graph 
o  reset  user  timer,  to  time  how  long  it  takes  operator  to  find  the  target  that 
was  just  placed 

o  tell  AIMSsim  to  run  streamLog.lua  every  time  step  during  search,  to 
capture  sensor  positions  to  file,  e.g.  for  debugging 

•  toCapture.lua: 

o  Button  9  has  been  pressed,  so  operator  has  made  decision:  stop  script  and 
clear  target(s) 

o  get  time  take  for  search/find 

o  tell  simDisplay  to  capture  current  camera  view  (of  which  sensor?);  once 
captured,  simDisplay  generates  IMAGECAPTURED  event 
automatically 

•  toQuestion.lua: 

o  camera  view  has  been  capture  so  reset  user  timer  to  time  how  long  taken 
to  answer  upcoming  question 
o  get  the  question  type  for  current  "target  event"  number 
o  tell  simDisplay  to  display  the  question  string 

•  toExit.lua: 

o  tell  simDisplay  to  exit  too 
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4  Common  Experiment  Tasks 


4.1  Starting  and  Exiting  the  AIMSsim  HMI  Prototype 

AIMSsim  must  be  started  at  a  DOS  command  line  (though  a  desktop  shortcut  could  be 
created).  Command  line  parameters  are  options  that  are  provided  to  simControl  to 
specify  some  of  its  run  time  parameters.  In  order  for  the  HMI  Prototype  to  function 
correctly,  one  command  line  parameter  is  required  for  the  initialization  script  to  use, 
and  a  number  of  optional  parameters  are  possible.  The  basic  steps  for  running  the  HMI 
Prototype: 


•  Open  a  command  shell,  e.g.  by  doing  Start->Run...->  ”cmd” 

•  Cd  to  the  folder  containing  the  AIMSsim  binaries  (AIMSHOME) 

•  Run 

simControl  -i  initscript .  lua  -p  subject jmmber  -t  trial  number 
Where: 

•  initscript.  lua  is  the  filename  of  the  AIMSsim  LUA  initialization  script, 
relative  to  the  current  directory;  e.g.  TEST/main.lua.  Note  that  path  must  be 
formatted  in  universal  form  rather  than  DOS  form,  i.e.  use  forward  slashes  as 
folder  separators. 

•  subject  jmmber  and  trial  jmmber  are  optional  numeric  parameters  used  to 
identify  and  name  the  data  collection  files  that  will  be  created  by  AIMSsim. 

If  subject  jmmber  and  trial  jmmber  are  not  provided,  AIMSsim  will  assign 
default  values  of  0  and  0,  respectively. 

Most  environment  variables  that  were  available  in  previous  generations  of  AIMSsim 
have  been  removed  or  replaced  with  corresponding  AIMSsim  variables  exported  to  the 
the  LUA  scripting  engine.  Refer  to  AIMSsim  System  Manual  for  a  list  of  all 
environment  variables  currently  supported,  and  to  section  2.3  of  the  current  manual  for 
example  settings  of  some  of  them. 

AIMSsim  will  give  best  results  when  it  is  run  covering  the  entire  screen  of  the 
monitor.  A  useful  key  combination  is  ALT-tab,  which  cycles  between  open  windows 
of  the  desktop. 

4.1.1  Initial  View 

Once  started,  simControl  spawns  off  two  other  processes,  namely  simlnputs  and 
simDisplay.  The  former  is  to  read  the  controls  box  (e.g.  a  FlyBox™),  the  latter  is  the 
display  side  of  the  system,  as  described  in  the  AIMSsim  System  Manual.  SimControl 
then  enters  the  “INIT”  state,  and  loops  forever,  waiting  for  events.  It  is  up  to  the 
initialization  script  to  transition  simControl  out  of  the  “INIT”  state,  but  it  is  up  to  one 
of  the  FSM  scripts  to  transition  it  to  the  “EXIT”  state  according  to  the  desired  flow  of 
the  experiment.  SimDisplay  will  show  an  essentially  empty  screen  (see  Figure  5). 
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Figure  5.  AIMSsim  display  in  “INIT”  state 

The  capabilities  of  AIMSsim  (i.e.  simControl  and  simDisplay  together)  between  the 
“INIT”  and  “EXIT”  states  are  entirely  determined  by  the  AIMSsim  and  LUA  functions 
and  variables  used  in  the  LUA  scripts. 

4.1.2  Controls 

There  are  two  types  of  controls  available  to  the  experiment:  analog  and  digital.  The 
analog  controls  are  continuous  variables  that  vary  between  -1  and  1.  The  association 
between  a  given  analog  control  and  its  effect  in  AIMSsim  is  hardcoded,  though  in 
some  cases  it  can  be  disabled: 

•  There  is  a  joystick  to  rotate  the  camera’s  view  location.  This  is  operational  only 
when  the  exported  orientationControl  variable  is  ORIENT_CTL_OPERATOR. 

•  There  is  a  zoom  in/zoom  out  function  that  uses  the  levers  for  continuous  zoom: 
the  left  lever  controls  the  top  view  (AGTV)  and  the  right  lever  controls  the 
bottom  view  (FLIR). 

All  digital  controls  are  either  on  or  off  and  generate  an  event  when  pressed  or  released. 
It  is  up  to  the  experiment  designer  to  decide  how  to  make  use  of  each  (or  any)  digital 
control  in  their  FSM.  All  digital  control  event  names  have  the  form 
EVENT  :  COIVTROE_PRESSED  and  EVENT  :  COI\JTNOL_RELEASED,  where 
CONTROL  is  described  in  Table  4. 

4.2  Common  experiment  tasks 

Some  tasks  or  activities  that  you  will  likely  perform  in  your  LUA  scripts  may  not  be 
obvious  from  the  exported  AIMSsim  functions  and  variables  shown  in  Annex  A.  A 
few  of  them  are  described  here.  Also,  the  available  screens  are  documented  here.  A 
good  way  of  acquiring  a  good  understanding  of  how  to  use  AIMSsim  is  by  looking  at 
some  of  the  sample  scripts  in  the  TEST,  LuaUtils  and  Designation  folders. 

4.2.1  Wait  to  start 

If  you  want  the  user  to  have  to  press  “Start”  before  some  stage  of  the  experiment,  a 
“Press  Start”  screen  is  available,  shown  in  Figure  6.  This  can  be  used  to  start  the 
experiment  after  everything  is  loaded  and  initialized,  or  between  two  phases  of  the 


14 


DRDC  Atlantic  CR  2006-280 


experiment,  etc.  Simply  send  a  message  to  simDisplay  with 
SendMessage  ("toStartup") .  When  the  operator  clicks  “Start”,  the 
EVENT  :  START_PRESSED  event  is  generated. 


DRIX'-A  F.LVISS  HMI  Expcnmcnlul  Prototype 

( c )  Her  Majesty  the  (Joccn  ui  Right  of  (anaJj  as  Represented 
by  die  Minuter  of  Nuliieul  Defence 
July  2005 


Tins  i«  a  Prototype  and  not  all 
ConWols  and  or  Functionality 
have  been  fully  implemented 


Figure  6.  Available  AIMSsim  "Press  Start"  screen 


4.2.2  Wait  to  exit 

An  exit  screen  waiting  for  the  user  to  press  the  “Exit”  button  is  available,  see  Figure  7. 
This  can  help  the  operator  know  that  the  programming  is  terminating  normally.  When 
the  operator  presses  “Exit”,  the  EVENT  :  EXIT_PRESSED  system  event  is  generated. 
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DRDC-A  ELV1SS  HMI  Fxpcrimcnlal  Prototype 

Experiment  Completed 


PWmc  itci  die  l  \pcnmc liter 


Prets  to  Exit 


Figure  7.  Available  AIMSsim  "Exit"  screen 


4.2.3  Show  Operator  screen 

The  screen  that  shows  the  sensor  camera  views  as  well  as  the  map  view  is  called  the 
“Operator”  screen.  Which  views  are  active,  as  well  as  various  sensor  and  map 
characteristics  which  will  affect  how  things  are  displayed,  can  be  set  via  the  many 
exported  AIMSsim  variables  shown  in  Annex  A. 

This  screen  is  activated  by  a  £e«d'Massage(“toOperational”).  This  screen  typically 
involves  a  substantial  amount  of  visual  detail,  such  that  activating  it  may  take  a  long 
time  (many  seconds).  During  this  time,  the  simControl  is  still  running,  but  simDisplay 
doesn’t  respond  or  update  the  screen.  This  can  be  somewhat  confusing  to  the  user  but 
it  is  up  to  the  experimenter  to  warn  them. 

Whenever  the  Operator  screen  becomes  visible,  a 

EVENT  :  OPERATIONAL_UPDATED  event  is  generated,  for  the  benefit  of  your  ExS 
scripts.  This  could  be  useful,  e.g.,  to  have  the  aircraft  start  its  motion  on  its  flight  path 
only  once  the  Operator  screen  is  visible. 
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Figure  8.  Available  AIMSsim  "Operator"  screen 


4.2.4  Camera  motion  or  tracking 

The  default  behavior  of  the  system  is  to  mimic  the  behavior  of  the  camera  gimbal  of 
the  real  system,  which  is  to  leave  the  camera  “free”  to  maintain  its  orientation  in  space 
regardless  of  the  aircraft  orientation,  and  respond  to  operator  input.  This  is  the 
ORIENT_CTL_OPERATOR  mode  of  the  setting  orientationControl. 

If  the  script  should  take  over  the  camera  orientation,  e.g.  for  “ground  track  mode” 
(autotracking),  the  orientation  control  must  be  changed  to  ORIENTCTLCPU.  Only 
then  your  scripts  can  call  SetSensor Orientation^),  typically  via  a  periodic  script  added 
with  AddPeriodicScript  (“scrip  tname”) . 

The  SetSensorOrientationQ  function  specifies  the  sensor  orientation  via  heading  and 
pitch  angles.  When  autotracking  a  faraway  target  while  zoomed  in,  small  numerical 
errors  in  the  view  matrix  created  from  the  heading  and  pitch  can  lead  to  visible  amount 
of  “jitter”  for  the  target  being  tracked.  This  is  realistic  since  in  a  real  system,  the 
gimbal  motors  would  be  controlled  similarly.  However,  should  you  desire  to  remove 
any  form  of  jitter,  a  third  orientation  control  mode  is  available: 

ORIENT_CTL_LOOKAT.  This  generates  the  view  matrix  by  telling  simDisplay  which 
point  in  space  to  look  at  (via  the  SetDisplayLookA tPoint( )  function),  almost 
completely  removing  any  jitter. 
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4.2.5  LOS  and  Isect 


The  Line-Of-Sight  information  is  computed  by  simDisplay  at  every  time  step  and  is 
made  accessible  to  the  ExS  scripts  via  GetLOSPositionQ).  Because  the  scripts  are  run 
from  simControl ,  which  runs  asynchronously  in  parallel  with  simDisplay, 
GetLOSPositionQ}  gives  the  latest  LOS  accessible  to  simControl.  The  simDisplay  may 
have  in  the  meantime  changed  the  view.  Note  however  that  this  kind  of  lag  should 
only  lead  to  visible  effects  if  the  two  processes  are  looping  at  very  different  rates  (e.g., 
simControl  is  able  to  do  only  5  time  steps  per  second  due  to  massive  amount  of  data 
saving  in  the  ExS  scripts,  while  simDisplay  is  able  to  loop  60  times  per  second). 

An  alternative  is  to  get  simControl  to  compute  the  LOS  value  via 
GetL  OS  Posit  ion  (“control”) .  This  will  produce  a  value  that  is  consistent  with  the 
physical  state  of  the  world,  rather  than  the  visual  state  of  the  world.  It  is  likely  to  be 
“in  the  near  future”  of  the  visual  display.  The  lag  ahead  is  typically  on  the  order  of 
milliseconds,  hardly  worth  worrying  about,  but  can  have  visible  effects  (in  terms  of 
decisions  made  by  the  scripts)  if  the  two  processes  are  looping  at  very  different  rates. 

Isects  are  the  name  give  to  the  result  of  getting  the  intersection  point  between  a  line 
and  a  surface.  An  isect  is  said  to  be  “invalid”  if  there  is  no  such  intersection.  In  the 
context  of  AIMSsim,  all  isects  are  for  a  line  starting  at  aircraft  location,  and  having  a 
certain  pitch  and  bearing.  Isects  typically  don’t  have  a  visual  component  and  are  useful 
mostly  to  the  scripts.  For  this  reason,  the  default  Requestlsect(bearing,  pitch)  get  the 
isect  as  computed  by  simControl. 

Due  to  the  asynchronicity  of  simDisplay  and  simControl,  the  isection  may  produce  a 
coordinate  that  lies  on  a  surface  different  from  what  the  operator  is  currently  seeing 
(e.g.,  the  isect  result  may  correspond  to  the  hood  of  a  truck  on  the  ground,  but  if  the 
truck  is  moving,  the  simDisplay  may  not  yet  have  received  its  new  position).  In  the 
rare  case  that  this  matters,  your  script  can  use  instead  RequestlsectQbearing,  pitch, 
“display”)  to  get  it  computed  by  the  display.  As  soon  as  the  display  has  the  result,  an 
EVENTTSECT  VALID  is  emitted  only  if  a  valid  isect  was  found.  However,  the 
asynchronicity  implies  that  by  the  time  your  script  gets  run  due  to  the  event,  the  world 
may  already  have  been  evolved  by  simControl.  Typically  the  change  will  be  small,  but 
there  are  situations  where  it  could  be  noticeable. 


4.2.6  Timing 

There  are  three  concepts  of  time  in  AIMSsim: 

•  Run  time:  time  since  the  beginning  of  the  run,  in  seconds.  Obtained  in  the 
experiment  scripts  by  calling  GetRuntime  ( )  .  This  cannot  be  paused  or  reset. 

•  Simulation  time:  time  since  any  motion  started,  also  in  seconds.  There  is  motion 
if  any  of  the  entities  is  resumed  via  an  appropriate  call  to  one  of  the  path  plan 
following  functions  (PathFollowing*()  or  AircraftPathFollowing*Q)  or 
TargetPathFollowing*( )).  This  timer  pauses  when  there  are  no  moving  entities. 
Therefore,  “pausing  the  simulation”  requires  that  all  entities  be  paused  (e.g.,  via  a 
call  to  PathFollowingPauseQ)).  Therefore  if  the  runtime  indicates  N  seconds  since 
the  beginning  of  the  experiment,  and  the  simulation  was  paused  once  for  P 1 
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seconds  and  another  time  for  P2  seconds,  then  the  simulation  time  at  exit  will  be 
N  -  PI  -  P2.  Note  that  the  simulation  time  is  displayed  by  simDisplay  in  the  top 
right  comer  of  the  Operator  screen.  Note  also  that  the  simulation  time  can  be  reset 
to  0  by  calling  GenerateEvent  ( "EVENT : RESET_SIM_TIME" )  . 

•  User  time:  time  since  the  last  ResetUserTimerQ  was  called.  Obtained  in  the 
experiment  scripts  by  calling  GetUserElapsedTimeQ.  Useful  to  measure  the  time 
differences. 

It  is  important  to  bear  in  mind  that  AddTimedEventQ  uses  the  run  time,  whereas 
A dd El igh t T im edE ven t( )  uses  the  simulation  time. 


4.2.7  Do  a  task  at  every  time  step 

If  your  experiment  needs  to  perform  a  task  at  every  time  step,  you  can  use 
AddPeriodicScript(“scv\ptN'dmc”)  to  tell  simControl  to  execute  a  script.  Periodic 
scripts  can  also  be  removed  from  the  list  of  periodic  scripts.  Note  that  the  order  of 
execution  of  periodic  scripts  is  not  guaranteed  and  should  not  be  relied  upon.  Note  also 
that  adding/removing  a  periodic  script  from  a  periodic  script  will  see  the  change 
activated  at  the  next  time  step  (so  as  not  to  corrupt  the  list  of  scripts  while  it  is  being 
traversed). 


4.2.8  Events 

Events  are  the  main  mechanism  for  indicating  to  the  application  that  “something  has 
happened”.  However,  events  are  useful  only  if  the  FSM  has  transitions  defined:  the 
only  way  to  “do  something”  when  an  event  “occurs”,  is  to  have  a  transition  defined  for 
it  in  the  FSM. 

There  are  several  ways  of  generating  events: 

•  By  pressing  or  releasing  a  digital  control  on  the  input  device 

•  By  clicking  on  a  button  on  a  dialog  screen  on  the  display 

•  By  calling  Ge«era?e£Ve77t(“EVENT:Name”)  to  generate  an  event  of  given 
name 

•  By  using  AddTimedEventQ  or  AddFlightTimedEventQ.  This  will  generate  the 
specified  event  at  the  specified  time:  if  the  event  appears  in  the  FSM,  a 
transition  could  occur.  The  two  timed  event  queues  can  be  cleared  with  a  call 
to  Clear Events{). 

Events  that  are  generated  during  a  time  step  are  queued  for  processing  at  the  next  time 
step,  when  they  will  be  generated  in  the  same  order  as  they  were  queued. 

Another  form  of  event  is  specific  to  simDisplay.  a  call  to  S e  >  i  d  Mess  age  ( “  m  c  s  s  a  g  c  ” ) 
sends  the  given  text  to  simDisplay.  Note  that  the  order  of  receipt  of  messages  and 
events  cannot  be  guaranteed  by  simDisplay  because  the  associated  data  is 
communicated  to  simDisplay  over  independent  channels.  A  simple  example  is 
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UpdateDisplayedTargetsQ :  this  actually  uses  SendMessageQ,  so  the  message  could  be 
received  (in  principle)  before  simDisplay' s  shared  memory  has  been  updated  with  the 
new  target  attributes. 


4.2.9  Aircraft  motion 

The  flight  plan  of  the  aircraft  is  set  with  the  A  ire  raft  A  dd  Pa  th  ( )  function,  which  takes 
as  argument  a  path  plan  created  with  Create  Path  Plaii().  The  A  ircra ft  A  d d  PathQ 
function  can  be  called  multiple  times  to  extend  the  aircraft’s  flight  plan  (see  the  section 
4.2.1 1  on  path  planning,  for  a  discussion  of  how  path  plans  are  strung  together). 
Wheverever  the  aircraft  reaches  the  end  of  the  last  path  given  to  it,  an 
EVENT :END_OF_PATH:  AIRCRAFT  is  generated. 

The  motion  of  the  aircraft  is  enabled  and  disabled  by  A  ire  raf t  Pat  h  Follow  ing*Q 
functions,  where  is  either  Pause,  Resume  or  Toggle. 

Note  that  the  motion  can  also  be  enabled/disabled  by  the  global  PathFollowing*{ ) 
functions,  which  affect  all  moving  entities  (aircraft  and  targets,  as  appropriate),  or  a 
list  of  specified  entities.  E.g. 

PathFollowingToggle ( ) 

would  pause  the  path  following  of  all  entities  that  were  moving,  and  resume  all  entities 
that  were  paused.  Whereas 

PathFollowingToggle ("aircraft",  "target  one",  "target  last") 

would  do  this  only  to  the  specified  entities  (“aircraft”  is  the  aircraft’s  “name”  as 
known  by  the  system  -  it  cannot  be  changed).  However,  always  use  one  of  the 
AircraftPathFollowing*Q  functions  instead  of  calling  Pa  th  Foil  o  wing*  (“airc  raft’  ’ ) . 


4.2.10  Targets 

Experiments  can  define  targets  ( CreateTargetQ )  and  clear  the  list  of  targets 
(i ClearTargetsQ )  at  any  time.  It  is  up  to  your  script  to  decide  if  and  when  to  let 
simDisplay  know  that  it  should  update  the  display  with  the  new  information,  via  a  call 
to  UpdateDisplayedTargetsQ )  (without  arguments). 

Each  target  has  attributes  that  can  be  modified  at  any  time  via  the  exported 
TargetChangeAttribQ  function.  As  with  the  creation/deletion  functions,  your 
experiment  scripts  must  tell  simDisplay  (when)  to  update  itself.  To  save  time,  you  can 
give  a  sequence  of  target  names  as  arguments  to  UpdateDisplayedTargetsQ  so 
simDisplay  will  update  only  those  targets  (this  cannot  be  done  when  creating/deleting 
targets). 

The  TargetChangeAttribQ  function  always  has  as  first  argument  the  target’s  name,  the 
attribute  name,  and  one  or  more  parameters  for  the  new  attribute  value.  Some 
attributes,  such  as  the  target  label,  require  only  one  such  parameter  (the  label  string), 
whereas  others  require  more:  the  position,  e.g.,  requires  three  (time  step,  new  x,  and 
new  y).  Similarly,  TargetGetAttribQ  returns  one,  two  or  three  values,  based  on  the 
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attribute  type  whose  value  is  being  queried.  E.g.  TargetGetAttrib  ("target 
B",  "pos")  returns  a  triplet  x,y,z,  whereas  TargetGetAttrib  ("target  B", 
"isTarget")  returns  a  boolean. 

Note  that  targets  get  their  Z  coordinate  automatically  clamped  so  the  target  is  on  the 
ground,  regardless  of  its  initial  Z  coordinate  value.  Currently,  flying  targets  are  not 
possible  (unless  there  is  no  ground  under  or  above  them). 

Targets  are  considered  vehicles:  they  can  have  motion,  just  like  the  aircraft  does: 
TargetAddPathQ,  Target  Pa  th  Foil  o  wing*  ( )  are  available  and  have  the  same  function  as 
for  aircraft,  but  they  apply  only  to  the  target  specified  by  name  in  the  first  function 
argument. 

When  a  target  reaches  the  end  of  the  most  recently  add  path  plan,  the  system  generates 
an  E  VENT :  ENDOFP  ATH :  5 UFF/X  event,  where  SUFFIX  is  by  default  the  target 
name  (converted  to  all  upper-case  letters,  and  with  all  spaces  converted  to  underscore). 
This  suffix  can  be  changed  via  TargetSetEndOfPathEventSuffixQ.  E.g.  given  a  target 
named  “first  target”,  the  default  “end  of  path”  event  name  for  that  target  is 
EVENT :END_OF_PATH:FIRST_TARGET.  After  calling 
TargetSetEndOJPathEventSuffix(“first  target”,  “Group  1”),  the  next  “end  of  path” 
event  for  that  target  will  be  named  EVENT:END_OF_PATH:GROUP_l. 

Note  that  targets  can  also  be  moved  manually  (e.g.,  if  the  ExS  scripts  define  a  special 
path  following  algorithm)  via  the  TargetChangeA  ttrib( )  function,  i.e.  without  using 
any  of  the  path  plan  following  functionality  of  the  system. 


4.2.11  Path  planning 

The  concept  of  path  following  is  available  to  both  types  of  vehicle  entities:  aircraft  and 
targets.  This  allows  both  the  aircraft  and  targets  to  follow  paths  independently.  Path 
following  is  supported  via  PathPlan  objects  created  with  CreatePathPlanQ,  and  the 
addition  of  such  objects  to  the  vehicles  by  calling  the  *AddPathQ  function  on  that 
vehicle,  at  any  moment  during  the  simulation.  Path  plans  can  be  sequenced  to  form 
more  complex  plans. 

Path  plans  are  considered  as  objects  by  the  system  and  are  copied  into  the  vehicles 
when  the  *AddPath( )  function  is  called.  Some  important  consequences  of  this: 

•  One  path  plan  can  be  reused  by  several  different  vehicles,  including  the 
aircraft 

•  One  path  plan  can  be  used  several  times  by  the  same  vehicle 

•  Modifying  a  path  plan  after  it  has  been  added  to  a  vehicle  does  not  affect  the 
vehicle’s  plan 

Note  however  that  path  plan  waypoints  contain  speed  and  fillet  information.  If  either 
of  those  must  change  for  different  vehicles  (usually  the  case  if  a  path  plan  is  going  to 
be  used  for  both  the  aircraft  and  some  land  vehicles  (targets),  you  can  copy  the  points 
of  one  plan  into  another  with  Pa  th  Plan  Get  Firs  t  Waypo  in  t{ )  and 
Pa  th  Plan  Get  Next  Waypo  intQ,  applying  any  transformation  desired.  E.g. 
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CreatePathPlan ( "target  path" ) 

x,y,z,s,r  =  PathPlanGetFirstWaypoint ( "aircraf tPath" ) 
while  x  ~=  nil  do 

PathPlanAddWaypoint ( "target  1  path",  x, y, z, s/10, r) 
x,y, z,s,r  =  PathPlanGetNextWaypoint ( "aircraf tPath" ) 

end 


creates  a  new  path,  named  “target  path”,  identical  to  another  (already  created  and 
populated)  path  plan  named  “aircraftPath”,  but  with  1/1 0th  the  speed  for  every 
waypoint. 

Several  path  plan  objects  can  be  added  to  a  vehicle,  thus  forming  a  longer,  more 
complex  path.  Path  plans  are  automatically  translated  and  rotated  when  they  are  added 
to  a  vehicle  that  is  already  on  a  path,  in  such  a  way  that  the  first  edge  of  the  added  path 
is  collinear  with  the  last  edge  of  the  previous  plan.  In  Figure  9  is  shown  a  simple  three- 
waypoint  path  plan  (left),  i.e.  consisting  of  two  edges.  The  right  side  of  the  figure 
shows  the  resulting  path  plan  for  a  vehicle  that  has  been  added  the  path  object  twice  in 
a  row: 


Figure  9.  Adding  a  path  a  second  time  to  a  vehicle 


This  affects  the  design  of  path  plans.  E.g.,  in  Figure  10,  adding  a  straight  path  to  a 
target,  then  adding  a  loop,  then  adding  the  straight  path  again,  leads  to  radically 
different  overall  path  for  the  vehicle,  depending  on  how  the  loop  was  designed.  The 
effect  in  A  is  typically  not  what  was  expected.  Notice  also  how  the  path  objects  are 
rotated  to  accommodate  the  colinearity  requirement. 
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Figure  10.  Adding  a  loop  between  two  copies  of  a  straight  path 


Path  following  typically  consists  in  the  following  steps: 

1.  Determine  which  paths  are  going  to  be  necessary  for  your  experiment; 

2.  Divide  your  paths  into  smaller,  reusable  “sections”,  if  this  helps  reduce  the  number 
or  complexity  of  paths  to  create; 

3.  Determine  if  and  how  to  react  to  EVENT:END_OF_PATH:*  events; 

4.  Add  the  necessary  EVENT:END_OF_PATEl:*  transitions  to  the  FSM,  and  the 
associated  transition  scripts; 

5.  Create  each  path  section  using  CreatePathPlan(“planName”),  then  calling 
Path  Plan  Add  WaypointC  p\imN'dmc'\  x,  y,  z,  speed,  fillet)  for  each  point  to  add  to 
the  plan.  This  can  be  combined  with  Path  Plan  Read  Waypoints  FileCphxnNamc”, 
“filename”)  to  add  the  points  from  a  file.  Either  way,  the  points  are  added  as-is  (no 
transformations  are  applied). 

6.  Add  any  combination  of  the  created  path  plan  objects  to  the  aircraft  with 
Aircraf  tAddPath  ("planName" )  .  The  first  plan  added  (and  only  the  very 
first  one)  sets  the  initial  position  of  the  aircraft  to  the  first  point  of  that  plan.  The 
remaining  plans  added  get  translated  and  rotated  so  that  their  first  segment  is 
collinear  with  the  previously  added  plan’s  last  segment  (see  below). 

7.  Position  targets  on  the  terrain; 

8.  Add  any  combination  of  the  created  path  plan  objects  to  any  target  with 
TargetAddPath  ("targetName",  "planName")  .  The  firstplanto  be 
added  gets  translated  to  the  target’s  current  location,  the  remaining  plans  gets 
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translated  and  rotated  so  that  their  first  segment  is  collinear  with  the  previously 
added  plan’s  last  segment  (see  below). 

9.  Resume  the  appropriate  vehicles  (aircraft  and  targets),  as  desired. 

The  different  default  behavior  for  the  first  call  to  TargetAddPathO  (for  a  given  target) 
compared  to  AircraftAddPathQ  shouldn’t  cause  you  any  surprise,  but  the  following 
may  help  clarify  further: 

There  is  only  one  aircraft,  and  it  will  almost  always  have  a  flight  plan;  so  the 
first  plan  added  determines  where  the  aircraft  starts  and  its  subsequent 
motion.  However,  there  are  typically  many  targets,  each  one  created  with  a 
specified  location,  and  typically  they  will  not  have  path  plans,  and  those  that 
do  will  often  use  common  path  object.  Therefore  it  makes  sense  for  path 
objects  to  get  repositioned  onto  targets  when  first  added. 

The  system  generates  EVENT:END_OF_PATH:*  events  only  when  the  end  of  the  last 
path  plan  added  is  reached,  since  the  last  resume.  E.g. 

Aircraf tAddPath ( "aircraf tPath" ) 

Aircraf tAddPath ( "aircraf tPath"  ) 

Aircraf tAddPath ( "aircraf tPath"  ) 

Aircraf tPathFollowingResume () 

will  cause  an  EVENT:END_OF_PATH: AIRCRAFT  event  to  be  generated  only  after 
the  end  of  the  third  path  section  has  been  reached. 


4.2.12  Save  data  to  a  file 

The  AIMSsim  does  not  create  any  output  files.  Rather,  output  files  are  created  by  the 
experimenter  from  the  LUA  scripts  using  the  native  LUA  output  capabilities. 

However,  if  having  each  line  of  output  timestamped  is  acceptable,  then  the  exported 
logging  facilities  are  by  far  the  easiest  and  most  robust  data  saving  mechanism.  This 
described  in  the  next  section. 

Whichever  technique  you  use,  AIMSsim  does  not  control  where  the  data  goes,  how  it 
is  formatted  in  the  output  file,  or  any  file  naming  conventions.  Some  file  naming 
conventions  that  have  worked  well,  for  various  types  of  files: 

•  Summary  file:  could  contain  summary  information  about  the  outcome  of  the 
experiment.  It  should  end  with  ^summary,  txt  and  not  involve  any  streaming 
data.  It  could  for  instance  show  the  duration  of  the  experiment,  the  tracking  score, 
etc. 

•  Stream  file:  contains  information  that  is  output  at  high  frequency  throughout  the 
experiment,  i.e  via  periodic  scripts.  E.g.  the  position  and  orientation  of  the 
simulated  search  aircraft.  It  should  end  with  _stream.txt  extension. 

•  Log  file:  contains  a  history  of  the  important  steps  or  computations  during  an 
experiment  it  shows  what  happened,  in  what  order.  It  should  end  with 

_log . txt . 
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•  Each  experiment  initialization  script  creates  a  “results  P  T”  folder  in  the 
experiment  folder,  where  P  and  T  are  the  participant  and  trial  number, 
respectively.  This  folder  name  can  be  stored  in  a  variable,  to  be  used  by  all  ExS 
scripts. 


4.2.13  Logging 

As  mentioned  in  the  system  manual  (Schoenbom,  2007),  all  three  of  the  AIMSsim 
processes  ( simlnput ,  simControl  and  simDisplay)  generate  their  own  log  file,  which 
gets  stored  in  the  folder  from  which  simControl  is  launched,  and  have  names  of  the 
form  '''process _ log.txt”  where  process  is  one  of  the  three  process  names.  All  processes 
use  the  same  logging  library,  which  supports  the  concept  of  “loggers”,  identified  by  a 
unique  character  string.  Each  logger  corresponds  to  a  certain  “category”  of  messages. 
For  instance,  the  “err.*”  logger  takes  care  of  all  error  messages,  whereas  the  “warn.*” 
logger  takes  care  of  all  the  warning  messages.  The  big  advantage  of  loggers  is 
uniformity  of  output,  time  stamping  of  all  messages,  and  the  ability  to  filter  the  output 
based  on  logger. 

The  set  of  loggers  known  to  a  given  process  cannot  be  changed.  However,  the  two 
functions  LogEnable( )  and  LogDisableQ  can  be  used  to  enable  and  disable  one  of 
simControl' s  loggers  (the  loggers  of  the  two  other  processes  cannot  be  changed).  E.g. 
the  LUA  tracing  messages  can  be  turned  on  or  off  at  any  time  by  calling 

LogEnable ( "trace . LUA" )  and  LogDisable ( "trace . LUA" )  . 

The  LogQ  function  outputs  its  argument  with  the  logger  called  “scriptLog.LUA”, 
which  can  be  similarly  enabled  or  disabled. 

You  can  tell  any  logger  to  duplicate  its  output  by  calling  the  LogAddOutputQ  function, 
The  second  argument  is  the  filename  that  will  receive  the  duplicated  output  for  the 
logger  (first  argument),  or  “stdouf  ’  if  the  output  should  be  duplicated  to  the  console. 
Note  that  currently,  there  is  no  LogRemoveOutputQ. 


4.2.14  Capture  display  screen 

Screen  shots  of  the  entire  display  can  be  captured  by  sending  a  message  to  simDisplay, 
i.e.  SendMessage  ("CAPTURE_SCREEN") .  The  pictures  are  saved  in  the  experiment’s 
folder,  in  a  subfolder  called  results/screens  (created  for  you  if  it  does  not  already 
exist),  as  a  JPEG  file  of  the  form  P_T_N  .  j  pg,  where  P=participant  #  (specified  on 
command  line,  0  if  not),  T=trial  #  (also  specified  on  command  line,  0  if  not),  and 
N=number  of  screen  shot  (N  is  automatically  determined  and  incremented  at  every 
screen  grab).  Note  that  image  files  are  overwritten  if  they  already  exist  (e.g.,  from  a 
previous  run).  E.g..,  if  the  experiment  is  Designation  (so  e.g.  the  main  script  is 
Designation/main .  lua),  then  the  first  screen  capture  will  go  to 
Designation/ results/ screens/ 0_0_0  .  jpg,  the  next  one  to 
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Designation/ results/ screens/ 0_0_1 .  jpg,  etc.  JPEG  files  can  be  viewed  with 
a  variety  of  software,  such  as  Internet  Explorer. 


4.3  Example  use 

In  this  section  we  give  an  example  of  sequence  of  steps  you  might  take  to  create  an 
experiment  and  run  it.  The  example  is  based  on  the  Spatial  Congruence  Experiment. 

File  definitions  and  locations: 

•  /user/people/ elviss/ newElviss/bin/NG/ SC  —  experiment  directory 

•  seen#  .  lua  -  scenario  definition  files 

•  SC/util  contains: 

o  Base .  fp  -  flight  plan  file  generated  by  Scenario  Generator 
o  Constants  .  lua  -  includes  flying  pitch,  target  pitch,  type,  and  8 
possible  bearings;  bearings  identify  speaker  positions 
o  Defaults  .  lua  -  AIMSsim  settings 

•  SC/results  -  contains  participant  log  files 

•  SC/generic  -  contains  script  files  that  implement  the  FSM  so  no  files  there 
should  be  changed,  except  toQuestion .  lua  (and  only  to  change  wording) 

Generating  scenario  files: 

•  Copy  scenl .  lua  into  scen2-6  .  lua 

•  Open  each  file  and  assign  it  appropriate  name  (on  top)  as  well  as  log  file 
name  (bottom) 

•  Set  map  orientation 

Defining  target: 

•  Get  appropriate  target  ID#  from  target  map .  txt  (in  NG)  and  change  type 

in  constants . lua 

•  If  new  target  is  to  be  used,  place  the  file  in  target  directory  (to  be  found  out), 
add  it  to  target  map .  txt,  assign  it  an  ID#  and  change  type  in 

constants . lua 

Defining  target  locations: 

•  8  target  location  for  each  flight  direction  (E/W) 

•  4  legs  (2  for  each  direction)  makes  4  targets  per  leg 

•  Number  of  targets  has  to  be  a  multiple  of  16,  to  have  location  x  flight 
direction  completely  crossed 

•  Number  of  legs  has  to  be  even,  to  have  equal  number  for  each  flight  direction 
Defining  flight  plan: 

•  Create  flight  plan  using  Scenario  Generation  Environment  (SGE) 

•  Copy  values  into  seen#  .  lua  (might  need  to  set  initial  aircraft  heading  or  the 
starting  point,  not  sure  about  this) 


26 


DRDC  Atlantic  CR  2006-280 


•  Leg  and  turn  lengths  need  to  be  the  same  across  scenarios,  different  starting 
points 

•  There  are  only  4  possible  starting  points:  left  and  right,  top  and  bottom; 
problem  if  multiple  flight  plans  used 

Generating  events: 

•  Once  flight  plan  is  defined,  fly  over  terrain  to  identify  time  ranges  for  each 
leg  during  which  events  can  occur 

•  Leave  5  seconds  at  beginning/end  of  each  leg  to  establish  RF;  also  5  seconds 
between  targets 

•  Randomly  select  times  for  each  event  within  the  given  ranges 

Generating  target  locations: 

•  Generate  two  sets  of  randomly  ordered  numbers  from  1  to  8,  one  for  each 
flight  direction 

•  Assign  numbers  from  first  set  to  odd  legs,  and  from  second  set  to  even  legs 
(odd:  1-4  and  9-12;  even:  5-8  and  13-16) 

Defining  audio  channels: 

•  Current  set-up  (constants  .  lua) 


o 

1 

(target  location)  =  330  deg 

o 

2 

=  30 

o 

3 

=  60 

o 

4 

=  120 

o 

5 

=  150 

o 

6 

=  210 

o 

7 

=  240 

o 

8 

=  300 

•  For  N-UP  conditions,  sound  location  will  be  the  same  as  target  locations 

•  For  A-UP  conditions,  sound  location  will  depend  on  flight  direction 


Flying  E 

Flying  W 

1  =  7 

1  =  3 

2  =  8 

2  =  4 

3  =  1 

3  =  5 

4  =  2 

4  =  6 

5  =  3 

5  =  7 

6  =  4 

6  =  8 

7  =  5 

7=1 

8  =  6 

8  =  2 
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List  of 

symbols/abbreviations/acronyms/initialisms 


Active  Gated  TV 

Advanced  Integrated  Multi-sensor  Surveillance 
AIMS  simulator 

Airborne  Laser-Based  Enhanced  Detection  and  Observation  System 
American  Standard  Code  for  Information  Interchange 


DND 

DREV 

Department  of  National  Defence 

Defence  Research  Establishment  Valcartier 

ELVISS 

Enhanced  Low-Light  Level  Visible  and  Infrared  Surveillance 
System 

FUR 

FLTK 

FOV 

FSM 

Forward  Looking  Infrared 

Fast  Light  Tool  Kit 

Field  of  View 

Finite  State  Machine 

HMI 

Human  Machine  Interface 

LOS 

Line  of  sight 

IR 

Infrared 

MMD 

Moving  Map  Display 

N/A 

Not  Applicable 

PC 

Personal  Computer 

SAR 

SGE 

SGI 

Search  and  Rescue 

Scenario  Generation  Environment 

Silicon  Graphics,  Inc. 

TOD 

Time  of  Day 

VAPS 

VPI 

Virtual  Applications  Prototyping  System 

Virtual  Prototypes,  Inc. 

Wx 

Weather 

AGTV 

AIMS 

AIMSsim 

ALBEDOS 

ASCII 
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Annex  A.  Exported  AIMSsim  Functions  and  Variables 


This  section  describes  all  AIMSsim  HMI  Prototype  functions  and  variables  available 
through  the  scripting  interface,  i.e.  that  have  been  exported  to  the  LUA  interpreter 
embedded  in  simControl. 

A.1  Exported  Functions 


Table  2.  Exported  functions  and  their  parameters 


Function 

Parameters 

Description 

Log 

string 

Logs  string  to  the  currently  set  log  file 

LogEnable/LogDi sable 

string  loggerName 

Enable/disable  output  of  log  messages  for  specified 
logger 

LogAddOutput 

string  loggerName, 
f ileName 

Duplicate  output  going  to  specified  logger  into 
specified  file.  If  file  name  is  “stdout”,  duplicates  to 
the  shell  window  (from  which  AIMSsim  was 
started) 

Set 

string  name, 
string/number  value 

Sets  a  system  variable  to  the  provided  value  -  see 
list  below 

Say 

string 

Deprecated  -  no  TTS  App 

PlaySpatial Sound 

number  channel 

Deprecated  -  no  sound  system 

GetVectorHP 

number  x,  y,  z 

Returns  the  heading,  pitch  for  the  given  vector  in 
world  frame.  Heading  0  implies  North  and 
increases  counterclockwise,  negative  pitch  is  below 
horizon.. 

GetLOSPosition 

none 

Returns  the  x,y,z  position  of  the  terrain  in  the 
centre  of  the  sensor  image  (Line  Of  Sight)  as 
computed  by  simDisplay. 

GetLOSPosition 

string  "control" 

Returns  the  x,y,z  position  of  the  terrain  in  the 
centre  of  the  sensor  image  (Line  Of  Sight)  as 
computed  by  simControl. 

GetSensor Orientation 

none 

Returns  the  h,p,r  orientation  of  the  sensor 

SetSensor Orientation 

number  h ,  p 

Set  new  heading  (and  pitch,  if  given)  of  sensor  pod. 
This  can  only  be  called  if 
orientationControl  has  been  set  to 

ORIENT  CTL  OPERATOR 

GetSensorFOV 

none 

Returns  the  Field  of  View  of  the  sensors 
(AGTV.FLIR) 

GetSensorZoom 

none 

Returns  the  zoom  factor  of  each  sensor 
(AGTV,FLIR),  a  value  between  0  (full  zoom  out) 
and  1  (full  zoom  in) 

GetViewportlnfo 

string  "AGTV"  or 
"FLIP" 

Returns  the  width,  height,  and  dots-per-inch  along 
width  and  height,  for  the  specified  sensor  display 

SetDisplayLookAtPoint 

number  x,  y,  z 

Set  the  world  coordinate  that  sensor  must  lock  onto 
if  the  orientationControl  is  set  to 

ORIENT  CTL  LOOKAT 

SetAutoScanlnfo 

string  state,  number 
center,  number  range 

If  first  arg  is  DISABLED,  disable  any  auto¬ 
scanning,  no  more  args  used;  if  ENABLED,  two 
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more  args  used:  center  of  scan  angle,  relative  to 
aircraft,  and  the  scan  range,  both  in  degrees 

AddPeriodicScript 

string  scriptName 

Adds  a  script  that  is  called  periodically  at  high 
frequency  -  useful  for  data  collection 

Clear Per iodicScripts 

none 

Clears  all  of  the  current  periodic  scripts 

RemovePeriodicScr ipt 

string  scriptName 

Remove  a  script  from  list  of  periodic  scripts;  does 
nothing  if  script  not  in  list 

AddTransition 

string  fromState, 
string  toState, 
string  triggerEvent, 
string  scriptName 

Adds  a  state  transition  to  help  define  the 
experiment  finite  state  machine 

AddTimedEvent 

string  eventName, 
number  eventTime 

Adds  an  event  to  occur  at  the  simulation  time 
provided;  more  than  one  time  can  be  given 

AddFlightTimedEvent 

string  eventName, 
number  eventTime 

Adds  an  event  to  occur  at  the  flight  time  provided; 
more  than  one  time  can  be  given 

GenerateEvent 

string  eventName 

Generates  an  event 

ClearEvents 

none 

Clears  all  pending  timed  events  (timed,  flight 
timed) 

SendMessage 

string  message 

Sends  a  control  message  to  the  UI  -  see  Table  5 

CreatePathPlan 

string  planName 

Create  a  new  path  plan 

PathPlanAddWaypoint 

string  planName, 
number  x,y,z,  speed 

Adds  a  waypoint  to  the  specified  path  plan 

PathPlanReadWaypointsFile 

string  planName, 
f ileName 

Read  the  specified  waypoints  file  (XML  file)  into 
the  specified  path  plan,  appending  the  points 

PathPlanGetFirstWaypoint 

string  planName 

Get  first  waypoint  of  a  plan 

PathPlanGetNextWaypoint 

string  planName 

Get  next  waypoint  of  a  plan,  nil  if  no  more  points 

PathPlanClear 

string  planName 

Clears  the  points  of  a  plan  (but  does  not  destroy 
plan) 

PathFollowingPause 

none,  or  sequence  of 
entity  names 

Pauses  the  path  following  behaviour  of  all  entities 
(including  aircraft)  if  no  arguments,  or  of  the 
specified  entities  if  given.  Use  “aircraft”  for  the 
aircraft  entity. 

PathFollowingResume 

string  planName 

Same  as  PathFollowingPause,  but  to  resume 

PathFollowingToggle 

string  planName 

Same  as  PathFollowingPause  but  toggles: 
resume  vehicle  motion  for  every  vehicle  if  paused, 
and  pause  if  resumed. 

Air craf tGet Position 

none 

Returns  the  x,y,z  position  of  the  aircraft 

Aircraf tGetOrientation 

none 

Returns  the  h,p,r  orientation  of  the  aircraft 

Air craf tGetVelocity 

none 

Returns  the  vx,vy,vz  velocity  of  the  aircraft 

Aircraf tAddPath 

string  planName 

Copy  the  specified  path  object  and  append  to  flight 
plan.  If  first  call,  also  positions  aircraft  onto  first 
point  of  path.  For  subsequent  calls,  the  path  plan 
copy  is  translated  and  rotated  so  the  common  point 
has  collinear  vertices. 

Aircraf t PathFollowingResume 

none 

Resume  motion  on  path;  does  nothing  if  end  of 
path  reached 

Aircraf t PathFollowingPause 

none 

Pause  motion  on  path 

Aircraf t PathFollowingToggle 

none 

Toggle  motion:  pause  if  resumed,  resume  if  paused 

AircraftPrintPath 

none 

Dump  information  about  the  complete  path  so  far; 
mostly  for  debugging  the  path  planning 

ReadTar gets File 

string  f  ileName 

Read  the  specified  targets  XML  file  and  create 
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targets;  this  appends  targets  to  current  set  of  targets 

ClearTargets 

none 

Removes  all  targets  from  the  scene 

UpdateDisplayedTargets 

none 

Causes  simDisplay  to  update  all  visual  aspects  of 
all  targets,  including  added/removed  targets 

UpdateDisplayedTargets 

string  targetlName, 
target2Name,  ... 

Causes  simDisplay  to  update  all  visual  aspects  of 
specified  targets;  only  valid  for  pre-existing  targets 

CreateTarget 

string  name,  number 
type,  x,y,z,h,p,r 

Adds  a  target  to  the  outside  scene  with  ID  name, 
and  type  as  an  index  in  the  targets.txt  file.  Places 
target  at  x,y,z,h,p,r 

TargetChangeAttrib 

string  targetName, 
attribName,  any 
newNalue 

Change  the  specified  target’s  specified  attribute  to 
new_value.  The  type  of  new_value  depends  on  the 
type  of  the  attribute.  Valid  attribute  names  and 
associated  new  value  type: 

label  string 

isTarget  boolean 

retroRef  lective  boolean 

colorOverrideAGTV  boolean 

colorOverrideFLIR  boolean 

colorlnAGTV  number,  0..1 

colorlnFLIR  number,  0..1 

TargetGetAttrib 

string  targetName, 
attribName 

Get  specified  attribute  from  specified  target.  Valid 
attribute  names  and  associated  value  type: 
label  string 

isTarget  boolean 

designationZoneRadius  boolean 
pos  x,  y,  z 

vel  vx,  vy,  vz 

TargetClampGround 

string  targetName 

Clamp  given  target  to  ground 

TargetAddPath 

string  targetName, 
planName 

Copy  the  specified  path  object  and  append  to 
vehicle  path  plan.  If  first  call,  translates  path  onto 
current  target  position.  For  subsequent  calls,  the 
path  plan  copy  is  translated  and  rotated  so  the 
common  point  has  collinear  vertices. 

TargetSetEndOf PathEvent Suffix 

string  targetName, 
suffix 

Changes  the  last  part  of  “end  of  path”  event  name 
for  specified  target.  Default  suffix  is  target’s  name. 
Note  that  suffix  is  always  converted  to  all- 
uppercase,  and  spaces  are  converted  to  underscore. 

TargetPathFollowingResume 

none 

Resume  motion  on  path;  does  nothing  if  end  of 
path  reached 

TargetPathFollowingPause 

none 

Pause  motion  on  path 

TargetPathFollowingToggle 

none 

Toggle  motion:  pause  if  resumed,  resume  if  paused 

GetRuntime 

none 

Returns  the  seconds  count  since  the  beginning  of 
the  simulation  (which  is  not  the  same  as  the 
simulation  time,  the  time  reported  in  the  top  right 
of  the  map) 

Re setUser Timer 

none 

Resets  the  user  timer  -  use  to  start  timing  a 
response 

GetUserElapsedTime 

none 

Returns  the  elapsed  time  in  seconds  since  the  user 
timer  was  last  reset 

Setlnt 

string  name,  number 
value 

Sets  the  named  user  variable  to  the  value  provided 

SetlntArrayElement 

string  name,  number 

Sets  the  value  of  the  named  array  at  the  index 
provided  to  the  value  provided 
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index,  number 
value 

SetFloatArrayElement 

string  name,  number 
index,  number 
value 

As  above,  but  for  floating  point  numbers 

Getlnt 

string  name 

Returns  the  value  of  the  named  user  variable 

GetlntArrayElement 

string  name,  number 
index 

Returns  the  named  and  indexed  value 

GetFloatArrayElement 

string  name,  number 
index 

As  above,  but  for  floating  point  numbers 

Requestlsect 

number  bearing, 
pitch 

Returns  validity,  x,  y,  z  for  a  line  leaving  aircraft 
with  bearing,  pitch  (given  in  world  frame).  Validity 
is  true  only  if  line  hits  terrain  or  a  target.  This  is 
computed  by  simControl. 

Requestlsect 

number  bearing, 
pitch,  string 
"display" 

Request  an  intersection  computation  from  aircraft 
to  terrain,  at  bearing  and  pitch  (given  in  world 
frame),  but  the  computation  will  be  done  by 
simDisplay  and  made  available  via  GetlsectPosQ 
after  an  EVENT:ISECT  VALID. 

GetlsectPos 

none 

Returns  the  x,y,z  location  of  the  last  intersection 
request.  Only  read  in  response  to  an 
EVENT:ISECT_VALID,  or  anytime  after  such  an 
event. 

Get Participant 

none 

Returns  the  current  participant  number 

GetTrial 

none 

Returns  the  current  trial  number 

A.2  Exported  Variables 

The  exported  variables  can  be  changed  through  the  exported  SetQ  function,  but  their 
state  can  not  be  queried. 


Table  3.  Exported  variables,  and  their  type  or  possible  values 


Variable  Name 

Value 

Description 

baseTerrain 

string 

The  path  and  name  of  the  base 
terrain  database 

polar Plot State 

ENABLED  |  DISABLED 

Sets  visibility  of  the  polar  plot, 
indicating  heading  of  sensor 
relative  to  aircraft 

agtvState 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  AGTV 
sensor  image 

f lirState 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  FLIR 
sensor  image 

mapState 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  Moving 

Map  Display 

autoTrackState 

ENABLED  |  DISABLED 

Tell  HMI  the  state  of  geo- 
stabilized  tracking  mode 

autoAlignState 

ENABLED  |  DISABLED 

Tell  HMI  the  state  of  auto- 
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alignment -to-aircraft-heading 

degredationState 

ENABLED  |  DISABLED 

Sets  image  degradation  for  the 
sensors 

timeOf Day 

Float,  0..1 

Sets  the  time  of  day  for  the 
darkness  of  the  AGTV  image;  0  = 
midnight,  1  =  noon 

primary Sens or 

PRIM_AGTV  |  PRIM_FLIR 

Sets  the  primary  sensor  to  AGTV 
or  FLIR,  this  affect  which  sensor 
footprint  displayed  in  MMD 

fogDistance 

Float  >=  0 

Sets  the  fog’s  zero  visibility 
distance 

fogOnset 

Float  >=  0 

Sets  the  onset  distance  for  the 
linear  fog 

fogColor 

Float,  0..1 

Color  of  fog 

orientationControl 

ORIENT_CTL_CPU, 

ORIENT_CTL_OPERATOR, 

ORIENT_CTL_LOOKAT 

Sets  whether  the  joystick 
movements  are  used  to  pan  camera 
(sensor  displays) 

j  oystickMode 

J  OY_MOD  E_AI  RC  RAFT 
JOY_MODE_CU  RSOR 

Sets  the  joystick  vertical  axes 
mode 

zoomDirMode 

ZOOM_MODE_FWD_ZOOM_IN 
ZOOM_MOD  E_FWD_Z00M_0 

UT 

Sets  which  direction  of  zoom 
levers  causes  zoom  in/out 

maxPitch 

Float,  -90. .90 

Sets  the  maximum  pitch  constraint 
on  camera 

minPitch 

Float,  -90. .90 

Sets  minimum  pitch  constraint  on 
camera 

mapFile 

string 

Sets  path  for  geometry  file  used  if 
mapMode  is 

MAPMODE2DPAPER, 
overriding  default 

mapAcSymbol State 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  map 
aircraft  symbol 

mapSensorFPState 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  map 
sensor  footprint 

mapSensor Hi storyS tat 
e 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  map 
sensor  history 

mapSensorHistoryRate 

SquareSize 

Float,  >=  0 

Sets  size  of  square  when  adding  a 
point  to  history;  typical  values  25m 
or  more 

mapSensorHistoryMaxA 

dd 

Int,  >=  0 

Maximum  number  of  history 
points  to  add  during  one  frame 

mapMar kingS t ate 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  map 
designate  markers 

mapFlight Paths t ate 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  map  flight 
path 

mapNorthlndicatorSta 

te 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  map  North 
indicator 

mapS caleDi splay St ate 

ENABLED  |  DISABLED 

Sets  the  visibility  of  the  map  scale 

mapColour 

ENABLED  DISABLED 

Sets  the  map  colour  mode 

mapOrientation 

MAP_ORIENT_NORTH_UP  | 

Sets  the  map  orientation  behaviour 
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MAP_ORIENT_AIRCRAFT_UP  | 
MAP_ORIENT_SENSOR_UP 

mapMode 

M AP_MO  D  E_2  D_P AP  E  R  | 

M  A  P_M  O  D  E_2  D_T  E  R  R  A 1 N 

Sets  the  map  mode 

mapScale 

float 

Sets  the  map  scale  desired; 
assumes  map  geometry  is  full-scale 

map Ac  S  ymb  o 1 T  yp e 

SYMB_HELO  |  SYMB_FIXED  | 
SYMB_POINT  |  SYMB_NONE 

Sets  map  symbol  type 

agtvColorDi splay 

ENABLED  |  DISABLED 

Enables/disables  the  color  mode  of 
AGTV  (default  disabled,  i.e.  gray) 

agtvIllState 

ENABLED  |  DISABLED 

Sets  the  state  of  the  AGTV 
Illuminator 

agtvIHFOV 

ILL_WIDE  |  ILL_NARROW 

Sets  the  width  of  the  AGTV 
illuminator 

agtvIUNarSize 

SENS_BEAM_NARROW_2  | 
SENS_BEAM_NARROW_5 

Sets  the  width  of  the  narrow 
illuminator 

agtvIHWidSize 

SENS_BEAM_WIDE_1 0  | 
SENS_BEAM_WIDE_1  5 
SENS_BEAM_WIDE_20 
SENS_BEAM_WIDE_25  | 

S  E  N  S_B  E  AM_WI  D  E_3  5 

Sets  the  width  of  the  wide 
illuminator 

agtvZoomMode 

ZOOM_WIDE  | 

ZOOM_N ARROW  | 
ZOOM_CONTINUOUS 

Sets  the  type  of  the  AGTV  zoom  to 
use 

agtvMaxZoomlndicator 

ENABLED  |  DISABLED 

Sets  the  state  of  the  maximum 
zoom  indicator  in  the  AGTV 

agtvMinFOV 

float 

Sets  the  minimum  FOV  of  the 

AGTV 

agtvMaxFOV 

float 

Sets  the  maximum  FOV  of  the 
AGTV 

agtvCurrentFOV 

float 

Sets  the  current  FOV  of  the  AGTV 

agtvDegredation 

float 

Sets  the  AGTV  degradation  factor 

agtvLODScale 

float 

Sets  the  AGTV  LOD  Scale 

f  lirPolarity 

POL_BLACK_HOT  | 
POL_WHITE_HOT 

Sets  the  FLIR  polarity 

f  lirZoomMode 

ZOOM_WIDE  | 

ZOOM_N ARROW  | 
ZOOM_CONTINUOUS 

Sets  the  state  of  the  FLIR  zoom 

f lirMaxZoomlndicator 

ENABLED  |  DISABLED 

Sets  the  state  of  the  maximum 
zoom  indicator  in  the  FLIR 

f lirZoomSlaved 

ENABLED  |  DISABLED 

Enables/disables  slaving  of  FLIR 
zoom  to  AGTV  zoom 

f lirMinFOV 

float 

Sets  the  minimum  FLIR  FOV 

f lirMaxFOV 

float 

Sets  the  maximum  FLIR  FOV 

f lirCurrentFOV 

float 

Sets  the  current  FLIR  FOV 

f lirDegredation 

float 

Sets  the  FLIR  degradation  factor 

f lirLODScale 

float 

Sets  the  FLIR  LOD  SCALE 

aircraf tX  ( YZHPR) 

float 

Sets  the  aircraft  location  and 
orientation 

reqBearing 

float 

Sets  the  requested  bearing  for  the 
LOS  intersection 
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reqPitch 

float 

Sets  the  requested  pitch  for  the 

LOS  intersection  test 

logFile 

string 

Sets  the  name  and  path  for  the  log 

file 
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Annex  B.  AIMSsim  System  Events  and  Messages 

There  are  several  predefined  events  that  are  generated  by  the  AIMSsim  HMI  Prototype 
under  various  conditions,  and  several  messages  that  can  be  sent  to  simDisplay  to  have 
it  perform  a  task  or  change  what  is  visible  on  the  display. 

Note  that  “intersection”  refers  to  the  intersection  between  the  Line  of  Sight  (LOS)  and 
the  ground  surface.  Such  a  test  yields  both  a  coordinate  of  the  intersection  point,  and 
the  normal  of  the  polygon  containing  the  intersection  point. 

Note  also  that  all  event  names  must  start  with  “EVENT:”  (not  shown  in  table,  for 
brevity). 

B.1  System  Events 


Table  4.  System  events  and  their  trigger  condition 


System  Event 

Trigger  Condition 

START  PRESSED 

The  start  button  on  the  Start  Screen  is  pressed 

EXIT  PRESSED 

The  exit  button  on  the  Exit  Screen  is  pressed 

ISECT  VALID 

The  requested  intersection  test  has  been 
completed 

IMAGE  CAPTURED 

The  screen  capture  request  has  been 
completed 

END  OF  PATH: AIRCRAFT 

The  aircraft  has  reached  the  end  of  its  flight 
plan 

END  OF  PATH : TARGET  NAME 

The  target  entity  named  TARGET  NAME 
has  reached  then  end  of  its  path;  note  that 
TARGET  NAME  is  the  name  of  the  target, 
with  all  letters  converted  to  uppercase,  and  all 
spaces  converted  to  underscore 

OPERATIONAL  UPDATED 

The  operational  view  of  the  display  is  now 
fully  visible;  this  gets  emitted  whenever  the 
display  gets  a  “toOperational”  command  (via 
SendMessage()) 

BUTTON  TLL 

Top  left-most  button 

BUTTON  TCL 

Top  left-of-center  button 

BUTTON  TCR 

Top  right-of-center  button 

BUTTON  TRR 

Top  right- most  button 

BUTTON  B?? 

Same  combinations  as  for  top  row,  but  for 
Bottom  row 
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JOYSTICK  TRIG1 

Big  trigger  on  joystick 

JOYSTICK  TRIG2 

Small  trigger  on  joystick 

JOYSTICK  4P  L 

Four-position  hat  left,  on  joystick 

JOYSTICK  4P  R 

Four-position  hat  right,  on  joystick 

JOYSTICK  4P  D 

Four-position  hat  down,  on  joystick 

JOYSTICK  4P  U 

Four-position  hat  up,  on  joystick 

JOYSTICK  2P  U 

Mini-hat  up,  on  joystick 

JOYSTICK  2P  D 

Mini-hat  down,  on  joystick 

LEVER  L  TRIG  L 

Left  lever’s  left  trigger 

LEVER  L  TRIG  R 

Left  lever’s  right  trigger 

LEVER  R  TRIG  L 

Right  lever’s  left  trigger 

LEVER  R  TRIG  R 

Right  lever’s  right  trigger 

B.2  Possible  Messages  to  SimDisplay  with  SendMessage() 

The  following  table  outlines  the  commands  that  can  be  sent  to  the  display  application 
using  the  SendMessageQ  function. 


Table  5.  Possible  messages  to  simDisplay  using  SendMessageQ 


Command 

Description 

toOperational 

Enables  the  “Operator  screen”  mode  of  the 
prototype.  This  causes  event 

event : operational  updated  to  be  generated  as 
soon  as  the  screen  becomes  visible. 

toStartup 

Displays  the  Startup  Screen 

toTrial 

Displays  the  Trial  Complete  Screen 

toHAK 

Displays  the  Flit  a  Key  Screen 

toBlank 

Displays  the  Blank  Screen 

toDisQ 

Displays  the  Discrete  Question  Screen 

toDirQ 

Displays  the  Direction  Question  Screen 

toExit 

Displays  the  Exit  Screen 

MARK  CONTACT 

Marks  the  Line-of-sight  isect  as  a  target  contact 
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UPDATE  TARGETS 

Updates  the  displayed  targets  list 

UPDATE  TARGETS  il  i2  ...  iN 

Same  as  update  targets  but  update  only  the 
targets  numbered  il,  i2,  etc.  This  message  is 
generated  by  the  system,  use 
UpdateDisplayedTargets{i\ ,  t2,  ...  tN)  instead, 
where  the  arguments  are  target  names 

REQUEST  I SECT 

Requests  an  LOS  intersection  test  for  the  bearing 
and  range  in  the  shared  memory.  It  is  better  to  use 
the  RequestlsectQ  function. 

CAPTURE  SCREEN 

Requests  a  screen  capture.  System  will  generate 

EVENT: IMAGE  CAPTURED 
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Annex  C.  AIMSsim  Target  Object  Types 


Included  with  the  delivery  of  the  AIMSsim  Prototype  System  is  a  library  of  target 
object  models.  These  models  may  be  used  as  targets/non-targets  for  the  creation  and 
execution  of  experimental  scenarios.  The  following  table  provides  the  names  of  the 
target  objects  and  a  description  of  each  object  model. 

Table  6.  Target  Object  Types 


NAME 

DESCRIPTION 

TruckJDesert 

Military  truck  with  desert  paint  scheme 

Truck_OD 

Military  truck  with  olive  drab  paint  scheme 

Hummer_Desert 

Military  jeep  with  desert  paint  scheme 

Hummer_OD 

Military  jeep  with  olive  drab  paint  scheme 

Leclerc_Tank_Desert 

LeClerc  (French)  tank  with  desert  paint  scheme 

Leclerc_Tank_Camo 

LeClerc  (French)  tank  with  camouflage  paint  scheme 

Leclerc_Tank_OD 

LeClerc  (French)  tank  with  olive  drab  paint  scheme 

T72_Tank_Desert 

T72  (Russian)  tank  with  desert  paint  scheme 

T72_Tank_OD 

T72  (Russian)  tank  with  olive  drab  paint  scheme 

OH58_Helicopter 

OH58  Kiowa  reconnaissance  helicopter 

AH64D_Helicopter 

AH64D  Longbow  apache  attack  helicopter 

A10_Fighter 

A10  Warthog  Anti-Tank  Aircraft 

PyramicMM 

Un-textured  1  meter  high  pyramid 

Pyramid_2M 

Un-textured  2  meter  high  pyramid 

Pyramid_3M 

Un-textured  3  meter  high  pyramid 

Diamond_1M 

Un-textured  1  meter  high  diamond 

Diamond_2M 

Un-textured  2  meter  high  diamond 

Diamond_3M 

Un-textured  3  meter  high  diamond 

Cube_1M 

Un-textured  1  meter  high  cube 

Cube_2M 

Un-textured  2  meter  high  cube 

Cube_3M 

Un-textured  3  meter  high  cube 

Cylinder_1M 

Un-textured  1  meter  high  cylinder 
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Cylinder_2M 

Cylinder_3M 

Pyramid_1  M_TEX 

Pyramid_2M_TEX 

Pyramid_3M_TEX 

Diamond_1_TEX 

Diamond_2M_TEX 

Diamond_3M_TEX 

Cube_1M_TEX 

Cube_2M_TEX 

Cube_3M_TEX 

Cylinder_1  M_TEX 

Cylinder_2M_TEX 

Cylinder_3M_TEX 

Murray 

Homer 


DRDC  Atlantic  CR  2006-280 


Un-textured  2  meter  high  cylinder 
Un-textured  3  meter  high  cylinder 
Textured  1  meter  high  pyramid 
Textured  2  meter  high  pyramid 
Textured  2  meter  high  pyramid 
Textured  1  meter  high  diamond 
Textured  2  meter  high  diamond 
Textured  3  meter  high  diamond 
Textured  1  meter  high  cube 
Textured  2  meter  high  cube 
Textured  3  meter  high  cube 
Textured  1  meter  high  cylinder 
Textured  2  meter  high  cylinder 
Textured  3  meter  high  cylinder 
“Murray”  person  figure 
“Homer  Simpson”  person  figure 


41 


Annex  D.  Converting  .fit  files  to  .ive 


OpenSceneGraph  accepts  a  variety  of  input  file  formats  for  geometry.  The  fastest 
format  to  load  is  a  binary  format  that  has  the  “ive”  extension.  The  program 
osgconv.exe  can  be  used  easily  to  convert  any  of  the  file  formats  understood  by 
OpenSceneGraph  to  any  other  format.  E.g.,  from  your  command  shell  you  could  do 

»  osgconv  truck. fit  truck. ive 

to  convert  the  truck  geometry  stored  as  an  OpenFlight  format  into  OpenSceneGraph’s 
binary  format.  The  above  assumes  you  have  downloaded  and  installed  osgconv  from 
the  OpenSceneGraph  web  site  (www.openscenegraph.org),  that  osgconv.exe  is  in  your 
PATH  environment  variable,  and  that  the  truck.flt  geometry  and  its  textures  are  in  the 
current  folder. 
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Annex  E.  AIMSsim  Scenario  Generation  Environment 


E.1  Introduction 

The  AIMSsim  Scenario  Generation  Environment  (SGE)  allows  you  to  define  the 
elements  required  to  create  an  experimental  scenario.  The  SGE  also  allows  you  to 
preview  some  elements  of  the  scenario  as  it  is  being  created.  Specifically,  you  can: 

•  Define  a  scenario  terrain  database  for  the  simulated  environment. 

•  Place  target  objects  into  the  simulated  environment. 

•  Define  a  flight  path  for  a  simulated  search  aircraft. 

•  Define  moving  map  characteristics. 

•  Adjust  various  simulated  sensor  characteristics. 

•  Adjust  simulated  environmental  conditions. 

•  Configure  the  layout  of  the  Human  Machine  Interface  (HMI). 

The  SGE  uses  a  project  concept.  An  SGE  project  is  a  collection  of  all  the  files  that 
together  make  up  an  experimental  scenario.  You  begin  by  planning  your  project  and 
then  create  various  files  as  you  perform  the  tasks  required  to  build  your  experimental 
scenario.  The  SGE  uses  four  files  to  define  a  scenario:  a  target  file,  a  flight  plan  file,  a 
configuration  file  and  a  project  file. 

•  The  target  file  ( targets. xml )  contains  the  information  required  to  represent  the 
placement  and  characteristics  of  all  targets  for  a  given  scenario. 

•  The  flight  plan  file  (flight-plan. xml )  contains  the  information  required  to  create  a 
flight  path  for  a  simulated  search  aircraft. 

•  The  configuration  file  ( config.xml )  contains  various  elements  of  scenario 
configuration  information  including  a  definition  of  the  Scenario  Landscape,  the 
configuration  of  the  simulated  sensors  and  the  configuration  of  the  HMI 
Prototype. 

•  The  project  file  ( project. xml)  contains  a  reference  to  a  target  file,  a  flight  plan  file 
and  a  configuration  file  which,  when  treated  as  a  group,  represent  a  complete 
experimental  scenario. 

Note  however  that  only  two  of  the  files  (i.e.  targets.xml  and  flightplan.xml)  produced 

by  the  SGE  are  usable  by  the  AIMSsim  HMI  Prototype,  a  significant  departure  from 

the  old  AIMSsim  system.  The  scenario  development  process,  if  you  wish  to  you  use 

the  SGE,  is  therefore  as  sketched  in  Figure  11. 
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Scenario  Generation 
Environment 


•Define/Place  target  objects 
•Define  simulated  search  aircraft 
flight  path 

•Adjust  sensor  characteristics 
•Define  environmental  conditions 
•Configure  user  interface  layout 


Text  editor  of  your  choice 


ELVISS  HMI  Prototype 


< 


I 


SGE 

project  files 


ELVISS 
Experiment 
LUA  scripts 


Figure  11.  AIMSsim  experiment  development  process  when  it  involves  the  SGE 


E.2  Starting  and  Exiting  the  SGE 

To  start  the  SGE  type  scenGen  in  a  command  prompt  window  open  to  the  location  of 
the  SGE  executable  file.  This  will  load  the  SGE.  You  may  also  double-click  on  this 
executable  file  on  your  desktop  or  from  the  Windows  Explorer  application  wherever  it 
happens  to  reside  on  your  local/network  drive. 

To  exit  the  SGE,  choose  File  |  Exit. 

E.3  A  quick  look  at  the  SGE 

Once  you  start  the  SGE,  you  will  use  various  controls  to  perform  your  scenario¬ 
building  tasks: 

•  The  Moving  Map  Display  (MMD)  and  Toolbar  allow  you  to  navigate  the  terrain 
and  scrutinize  the  placement  of  objects.  You  may  also  view  a  3D  display  of  the 
object  and  its  placement  in  the  terrain  by  pressing  the  ‘view’  button. 

•  The  Targets  tab  allows  you  to  add  and  delete  targets  from  the  scenario  as  well  as 
to  control  the  characteristics  of  the  targets. 

•  The  Aircraft  tab  allows  you  to  define  a  flight  path  for  a  simulated  search  aircraft. 

•  The  Sensors  tab  allows  you  to  control  the  characteristics  of  the  simulated  AGTV 
and  FLIR  sensors. 

•  The  Map  tab  allows  you  to  select  map  characteristics. 

•  The  Environment  tab  allows  you  adjust  environmental  settings  for  the  scenario. 

•  The  Misc  tab  allow  some  additional  settings  to  be  selected. 
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•  The  Altitude  Profile  Display  provides  you  with  information  about  the  altitude  of 
the  simulated  search  aircraft  with  respect  to  time. 

•  The  Scenario  Summary  provides  you  with  summary  information  about  the 
duration  of  the  current  scenario  and  the  number  of  targets/non-targets  defined  in 
the  current  scenario. 

The  SGE  also  includes  various  menus,  each  with  its  own  set  of  commands  and/or 
options  that  you  can  use  to  perform  functions  such  as  loading/saving  scenarios  and 
files  and  selecting  the  scenario  landscape. 

E.4  The  SGE  Interface 

The  SGE  interface  consists  of  a  single  window  that  is  divided  into  six  main  areas  and  a 
menu  bar,  as  illustrated  in  Figure  12.  The  options  provided  in  the  pull-down  menus 
are  described  in  the  following  sections. 


Figure  12.  SGE  Interface 


E.5  Using  the  AIMSsim  SGE 

The  following  sections  will  provide  information  about  using  the  SGE  to  perform  the 
standard  tasks  required  to  build  AIMSsim  experimental  scenarios. 
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1.  Defining  a  Scenario  Landscape  (Terrain) 

Each  AIMSsim  experimental  scenario  is  based  on  a  terrain  database.  To  open  a  database, 
use  Terrain  |  Select...  in  the  SGE  window.  Terrain  database  files  may  be  recognized  by 
the  .ive  file  extension.  Navigate  to  the  appropriate  directory  and  select  the  file  that  you 
want  to  open,  and  click  OK.  The  selected  terrain  database  appears  in  the  Moving  Map 
Display  (MMD)  area. 

The  terrain  databases  that  are  supplied  with  AIMSsim  include:  the  Certain  Impact 
database  and  the  Nerepis  database.  To  navigate  “certain  impact/models”  select 
“terrain.pfb”.  To  use  the  Nerepis  database,  follow  the  instructions  in  the  following 
paragraph. 

When  selecting  a  terrain  in  the  Nerepis  database  select  only:  NE,  SW,  NW,  or  SE.  When 
navigating  the  directories  that  contain  terrain  data  you  will  find  multiple  files:  one  with 
“_bw”,  “  shaded”,  or  “shadedbw”  in  the  name  and  one  without  (i.e.  terrain.pfb  and 
terrain  bw.pfb).  The  file  name  that  contains  “_bw”  is  the  black  and  white  version  of  the 
terrain  database  -  this  version  should  not  be  used  in  the  SGE  neither  should  “_shaded”, 
nor  “shaded  bw”.  Instead,  use  the  file  without  “_bw”  in  the  file  name  -  this  is  the  colour 
version  of  the  terrain  database  and  should  be  used  in  the  SGE. 

2.  Using  the  Moving  Map  Display 

The  SGE  allows  you  to  navigate  the  Scenario  Landscape  via  the  Moving  Map  Display 
(MMD)  which  is  located  in  the  box  on  the  left  hand  side  and  associated  Toolbar.  The 
main  purpose  of  the  MMD  is  to  provide  a  visual  overview  of  the  experimental  scenario 
and  to  facilitate  accurate  placement  of  scenario  elements  (targets  and  waypoints)  on  the 
Scenario  Landscape. 

a.  The  MMD  Toolbar 

The  MMD  Toolbar  provides  additional  tools  to  facilitate  the  manipulation  of  the  MMD 
(see  Figure  13).  The  Toolbar  provides  such  functions  as  Grab,  Centre  On,  Step  Zoom  In 
and  Step  Zoom  Out. 

The  Grab  tool  provides  an  easy  means  to  navigate  the  Scenario  Landscape  by  allowing 
the  user  to  grab  and  drag  the  terrain  in  any  direction.  To  use  the  Grab  tool,  simply  click 
on  the  Grab  tool  icon.  Now  use  the  left  mouse  button  to  select  a  drag  point  on  the  terrain 
and  with  the  left  mouse  button  depressed,  move  the  mouse  in  any  direction  to  drag  the 
terrain.  The  Grab  tool  mode  is  persistent,  so  when  you  have  finished  repositioning  the 
terrain,  de-select  the  grab  tool  by  clicking  on  the  Grab  tool  icon. 

The  Centre-On  tool  allows  you  to  select  a  point  on  the  Scenario  Landscape  that  you  wish 
to  specify  as  the  new  “centre”  for  the  MMD.  To  use  the  Centre-On  tool,  click  the  Centre- 
On  tool  icon.  Use  the  mouse  to  position  the  cursor  over  the  position  that  you  would  like 
to  specify  as  the  new  centre  for  the  MMD  and  depress  the  left  mouse  button  to  re-centre 
the  map.  The  Centre-On  tool  mode  is  also  persistent,  so  when  you  have  finished 
specifying  a  new  centre,  you  will  have  to  de-select  the  Centre-On  tool.  The  Centre-On 
function  is  particularly  useful  when  you  wish  to  quickly  zoom  in  on  a  specific  position  on 
the  terrain:  rather  than  having  to  use  a  combination  of  Grab  and  Zoom  actions  simply 
centre  on  the  area  of  interest  and  use  the  Step  Zoom  functions  to  achieve  the  desired  zoom 
level. 

The  Step  Zoom  In  and  Step  Zoom  Out  tools  allow  you  to  quickly  zoom  in  and  out  on  the 
MMD  in  an  incremental  fashion.  To  Step  Zoom  In:  click  on  the  Step  Zoom  In  icon. 
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To  Step  Zoom  Out:  click  on  the  Step  Zoom  Out  icon.  The  zoom  function  will  halve  the 
current  zoom  setting  or  double  the  current  zoom  setting,  as  appropriate. 


jvj*- 


Grab  Tool 
Centre  On  Tool 
Step  Zoom  In 
Step  Zoom  Out 


Figure  13.  MMD  Toolbar  Functions 


3.  Manipulating  Targets 

Target  objects  form  the  basis  for  the  search  and  detection  task  utilized  in  the  empirical 
investigation  of  AIMSsim  user  interface  issues.  A  target  is  a  three-dimensional  object  or 
3D  model  with  certain  scenario  related  characteristics  assigned  to  it  by  the  user.  Targets 
may  be  added  or  deleted  from  a  scenario.  The  target  manipulation  interface  is  presented 
in  Figure  14. 


Targets- 


One 
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Add 


Delete 


Selected  Target - 
Name 


Zero 


f  View 


T ype | A1 0_FIGHTER^J  Visibility | Both  ▼] 
Orientation(deg)  (T^)  _jJ[  0  _[J 
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[-Identifier - 
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Identifier  <> 


Label  0 


3] 
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X  Y 


19405  8700  |11052  5001  (218  8210 
Select  I 


Figure  14.  Target  Manipulation  Interface 

a.  Adding  a  Target 

In  the  tabbed  area  select  Targets.  The  target  manipulation  area  will  be 
displayed. 
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In  the  Targets  area,  add  a  target  by  clicking  the  Add  button.  A  new  target 
will  appear  in  the  target  browser.  It  will  have  been  assigned  a  default 
name  of  “Target”. 

At  this  point  a  target  icon  will  not  have  appeared  on  the  MMD.  This  is 
because  no  position  has  been  defined  for  the  newly  created  target.  To 
define  a  geographic  position  for  the  target  select  a  location  on  the 
Scenario  Landscape  by  clicking  on  the  MMD  in  the  location  where 
you’d  like  the  target  to  be  placed  and  then  click  the  Select  button  in 
the  Position  area. 

A  target  icon  will  appear  on  the  MMD  over  the  clicked  position  to 
indicate  the  selected  location  for  the  target.  Target  icons  appear  as 
boxes  containing  an  “x”  symbol”. 


In  order  to  achieve  the  most  accurate  placement  of  target  objects,  you 
should  zoom  in  to  the  desired  placement  area  on  the  MMD  before 
selecting  the  target  location. 


b.  Deleting  a  Target 

1.  In  the  tabbed  area,  select  Targets  if  it  is  not  already  selected.  The  target 
manipulation  area  will  be  displayed. 

2.  Select  the  target  you  wish  to  delete  via  the  target  browser.  It  will  become 
highlighted. 

3.  Delete  the  target  by  clicking  the  Delete  button. 

c.  Modifying  Target  Parameters 

Each  target  has  a  number  of  parameters  that  will  affect  the  way  the  target  will  be  utilized 
by  the  AIMSsim  HMI  Prototype.  The  following  table  describes  the  various  target 
parameters  and  how  to  manipulate  them. 


Table  7.  Target  Parameters 

PARAMETER 

NAME 

DESCRIPTION 

USE 

Name 

Assigns  an  alpha-numeric  name  to  the  target. 
The  name  is  used  to  identify  the  target  on  the 
MMD. 

Select  the  Name  field  and  type  a 
desired  name.  When  finished,  press 
the  <Enter>  key  to  apply  the  new  name. 

Target 

Flags  this  object  as  being  a  “Target”  object  (as 
opposed  to  a  non-target).  This  parameter  is 
used  for  scoring  purposes  when  an  HMI 
Prototype  use  has  been  asked  to  discriminate 
between  true  target  objects  and  false  target 
objects. 

Click  on  the  Target  radio  button  to 
toggle  the  target  setting.  Notice  that  the 
colour  of  the  target  icon  on  the  MMD  will 
toggle  between  red  and  green.  Red 
indicates  that  the  target  has  been 
flagged  as  a  true  target.  Green  signifies 
a  false  target. 

48 


DRDC  Atlantic  CR  2006-280 


Retro-Reflective  Flags  this  object  as  having  “retro-reflective”  Click  on  the  Retro-Reflective  radio 

characteristics.  This  parameter  will  affect  the  button  to  toggle  the  retro-reflective 
presentation  of  the  target  when  observed  in  the  setting.  Illuminated  indicates  retro- 
HMI  Prototype:  the  target  will  appear  to  “reflect”  reflective  property  enabled, 
the  light  emitted  by  the  laser  illuminator  when 
the  beam  is  positioned  on  the  target. 

Type  Defines  the  visual  representation  of  the  target  Select  a  type  from  the  Type  pick  list. 

(people,  vehicles,  aircraft  or  geometric  See  Annex  A  for  descriptions  of  the 
primitives).  targets 

Visibility  Defines  the  visibility  of  target  with  respect  to  the  Select  a  visibility  setting  from  the 

simulated  AGTV  and  FUR  sensors.  Visibility  pick  list.  Both  signifies  the 

target  will  be  visible  to  both  the 
simulated  AGTV  and  FUR  sensors. 
AGTV  Only  means  that  the  target  will 
be  visible  to  the  simulated  AGTV  only 
and  will  not  be  visible  by  the  FUR. 
FLIR  Only  means  that  the  target  will 
only  be  visible  to  the  simulated  FUR 
sensor  and  will  not  be  visible  to  the 
AGTV  sensor. 

Orientation  Assigns  an  orientation  or  heading  to  the  target  Adjust  the  Orientation  dial  to  specify 

object  allowing  it  to  be  rotated  to  face  in  any  the  desired  orientation  of  the  object, 
direction.  A  heading  of  0  is  equivalent  to  due  Alternatively,  you  may  increment  or 
North.  decrement  the  orientation  value  via  the 

Orientation  spin  box. 

Click  the  Colour  button  to  display  the 
target  colour  manipulation  window.  Use 
the  Enable  Colour  Adjustment  radio 
buttons  to  enable/disable  colour 
adjustment  for  the  current  target  as  it 
will  be  viewed  by  the  AGTV  and  FUR 
sensors.  When  colour  adjustment  is 
enabled,  use  the  slider  to  adjust  the 
target  colour  between  Dark  and  Light. 
When  you  have  finished  adjusting  target 
colour  settings,  click  OK  to  keep  you 
changes  or  Cancel  to  discard  any 
changes  you  have  made. 

Identifier  Flags  this  object  as  being  enhanced  by  an  Click  the  Identifier  radio  button  to 

identifier  label.  An  identifier  label  takes  the  form  select/deselect  the  target  identifier 
of  a  billboard  “sign”  that  will  be  presented  above  setting, 
the  target  model  representation  when  viewed  in 
the  HMI  Prototype. 

Label  When  the  Identifier  is  enabled,  Label  defines  Select  an  alpha-numeric  value  from  the 

the  alpha-numeric  character  that  will  be  visible  Label  pick-list.  This  parameter  will  only 
on  the  identifier  billboard.  have  an  effect  if  the  Identifier 

parameters  have  been  enabled. 

Position  Assigns  the  geographic  location  of  the  target  The  target  position  may  be  selected 

object  on  the  scenario  landscape.  The  position  interactively  by  clicking  the  Select 

is  specified  by  an  x,  y,  and  z  value.  These  button  and  then  clicking  on  a  location  on 
values  are  in  meters.  the  MMD.  Alternatively,  you  may  select 

and  type  discrete  values  into  the  x,  y 
and  z  fields  and  then  hit  <Enter>  to 
apply  the  new  value(s). 


Colour  Allows  you  to  modify  the  runtime  colour  of  the 

target  object  as  it  will  appear  to  the  AGTV  and 
FUR  sensors.  The  light  on  the  Colour  button 
determines  if  the  target  colour  has  been 
modified  (lit)  or  if  the  default  target  colour  is 
being  used  (unlit). 
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d.  Previewing  Target  Placement  and  Appearance 

The  SGE  allows  you  to  view  the  placement  and  appearance  of  the  targets  that  you  have 
created.  This  feature  is  particularly  useful  when  accurate  placement  of  objects  with 
respect  to  the  surrounding  terrain  is  desired  (i.e.  placing  an  object  between  two  buildings, 
behind  a  hill,  etc.).  The  view,  however,  does  not  reflect  the  weather  degradations  and  the 
colour  level  of  the  targets. 

To  view  a  target,  click  on  the  target  name  in  the  target  browser  and  press  the  ‘view’ 
button  to  toggle  the  target  view  mode.  A  3D  view  of  the  target  and  its  surrounding  terrain 
will  become  visible  in  the  MMD.  The  target  view  mode  is  presented  in  Figure  15. 


Figure  15.  Target  View  Mode 

In  target  view  mode,  the  selected  target  and  the  surrounding  scene  can  be  navigated  by 
using  the  left  and  right  mouse  buttons.  Using  the  left  mouse  button  allows  the  user  to 
rotate  the  target  and  the  scene  to  a  number  of  angles  and  views.  The  right  mouse  button 
allows  the  target  and  scene  to  be  zoomed  both  in  and  out.  When  you  are  finished  viewing 
the  target,  press  the  ‘view’  button  again  to  toggle  out  of  target  view  mode. 
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e.  Saving  the  Target  List 

Whenever  you  make  changes  to  your  targets  you  will  want  to  preserve  those  changes  by 
saving  the  target  list.  To  save  the  target  list,  select  File  |  Save  Targets  on  the  SGE 
window  menu  bar.  Use  the  file  browser  to  navigate  to  the  desired  directory.  The  target 
list  and  related  target  properties  will  be  saved  to  the  ‘targets.xmT  file  within  the  chosen 
directory.  Click  OK  to  save  the  target  file.  Alternatively  you  may  wish  to  overwrite  an 
existing  target  file.  In  this  case  use  the  file  browser  to  navigate  to  the  directory  that 
already  contains  the  ‘targets.xmT  file  that  you  wish  to  overwrite  and  click  OK. 

4.  Manipulating  the  Aircraft  Flight  Path 

In  order  to  represent  the  use  of  AIMS  from  an  airborne  platform,  the  AIMSsim  Prototype 
System  allows  you  to  define  a  flight  path  for  a  simulated  search  aircraft  to  which  the 
simulated  sensors  are  affixed.  The  SGE  allows  you  to  select  one  of  three  types  of  flight 
paths:  a  User  Defined  flight  path,  a  Creeping  Line  Ahead  flight  pattern  and  an  Expanding 
Square  flight  pattern. 

a.  User  Defined  Flight  Path 

The  User  Defined  flight  path  allows  you  to  create  a  flight  path  made  up  of  a  sequence  of 
waypoints  that  are  individually  placed  according  to  your  specifications.  You  may  specify 
the  location,  altitude  and  speed  of  the  simulated  search  aircraft  at  each  waypoint.  The 
User  Defined  flight  path  manipulation  interface  is  presented  in  Figure  16. 
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Figure  16.  User  Defined  Flight  Path  Manipulation  Interface 


b.  Adding  a  Waypoint 


1.  In  the  tabbed  area  select  Aircraft  then  select  the  User  Defined  tab.  The 
User  Defined  flight  path  manipulation  area  will  be  displayed. 

2.  In  the  Flight  Plan  area,  add  a  waypoint  by  clicking  the  Add  button.  A 
new  waypoint  will  appear  in  the  Waypoint  Browser.  The  SGE  will 
automatically  assign  a  name  to  the  waypoint  (i.e.  “Waypointl”). 
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3.  At  this  point  a  waypoint  icon  will  not  have  appeared  on  the  MMD.  This 
is  because  no  position  has  been  defined  for  the  newly  created  waypoint. 
To  define  a  geographic  position  for  the  waypoint,  select  a  location  on  the 
Scenario  Landscape  by  clicking  on  the  MMD  in  the  location  where  you’d 
like  the  waypoint  to  be  placed  and  then  click  the  Select  button  in  the 
Position  area. 

4.  A  waypoint  icon  will  appear  on  the  MMD  over  the  clicked  position  to 
indicate  the  selected  location  for  the  waypoint.  Waypoint  icons  appear  as 
cyan  coloured  stars.  Once  more  than  one  waypoint  has  been  defined,  the 
flight  path  will  appear  on  the  MMD  as  a  cyan  line  connecting  waypoint  to 
waypoint. 

5.  The  Altitude  Profile  Display  provides  you  with  information  about  the 
relative  altitude  of  your  waypoint  from  ground  level. 


In  order  to  achieve  a  more  accurate  placement  of  waypoints,  you  may 
want  to  zoom  into  the  desired  placement  area  on  the  MMD  before 
selecting  the  waypoint  location. 


c.  Deleting  a  Waypoint 

1 .  In  the  tabbed  are  select  Aircraft  if  it  is  not  already  selected.  The  flight 
path  manipulation  area  will  be  displayed. 

2.  Select  the  waypoint  you  wish  to  delete  via  the  Waypoint  Browser.  It  will 
become  highlighted. 

3.  Delete  the  waypoint  by  clicking  the  Delete  button.  Any  remaining 
waypoint  will  automatically  be  re-named  to  ensure  a  continuous  sequence 
of  numbers  in  the  flight  plan. 

d.  Modifying  Waypoint  Parameters 

Each  waypoint  has  a  number  of  parameters  that  will  affect  the  way  the  waypoint  will  be 
utilized  by  the  AIMSsim  HMI  Prototype.  The  following  table  describes  the  various 
waypoint  parameters  and  how  to  manipulate  them. 


Table  8.  User  Defined  Waypoint  Parameters 


PARAMETER  DESCRIPTION  USE 

NAME 


Position 


Assigns  the  geographic  location  of  the  waypoint 
object  on  the  scenario  landscape.  The  position 
is  specified  by  an  x,  y,  and  Altitude  value. 
These  values  are  in  meters. 


The  waypoint  position  may  be  selected 
interactively  by  clicking  the  Select 
button  and  then  clicking  on  a  location  on 
the  MMD.  Alternatively,  you  may  select 
and  type  discrete  values  into  the  x,  y 
and  Altitude  fields  and  then  hit  <Enter> 
to  apply  the  new  value(s). 
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Speed 


Assigns  a  speed  to  the  simulated  search  Click  on  the  increment  or  decrement 
aircraft  once  it  reaches  that  waypoint.  Speed  is  controls  on  the  Speed  spin  box  to 
specified  in  knots.  increase  or  decrease  the  speed  of  the 

simulated  search  aircraft. 


e.  Creeping  Line  Ahead  Flight  Pattern 

The  SGE  allows  you  to  generate  flight  patterns  that  are  commonly  employed  by  the 
search  and  rescue  community.  The  “Creeping  Line  Ahead”  is  one  of  these  patterns.  The 
“Creeping  Line  Ahead”  comprises  a  pattern  of  equally  spaced  parallel  lines.  It  is  a 
general  search  pattern  that  attempts  to  ensure  even  search  coverage  over  a  designated 
search  area.  A  “Creeping  Line  Ahead”  pattern  is  depicted  in  Figure  17. 


Figure  17.  Creeping  Line  Ahead  Search  Pattern 

By  providing  some  elementary  parameter  values,  the  SGE  will  automatically  generate  a 
sequence  of  waypoints  for  you. 

f.  Creating  a  Creeping  Line  Ahead  Flight  Pattern 

To  create  a  Creeping  Line  Ahead  flight  pattern: 

1 .  In  the  tabbed  area  select  Aircraft  then  select  the  Creeping  Line  tab.  The 
Creeping  Line  Ahead  flight  path  manipulation  area  will  be  displayed. 

2.  In  the  Start  Point  area,  designate  the  start  point  for  the  pattern  by  clicking 
a  location  on  the  MMD  and  then  pressing  the  Select  button.  The 
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Creeping  Line  Ahead  flight  pattern  will  be  displayed  on  the  MMD 
configured  with  default  parameter  values. 

g.  Modifying  the  Creeping  Line  Ahead  Flight  Pattern 

The  Creeping  Line  Ahead  flight  pattern  is  created  based  on  a  number  of  parameters. 
Changing  these  parameters  will  affect  the  geographic  area  that  the  pattern  will  cover  and 
the  rate  at  which  the  area  is  covered.  The  following  table  describes  the  various 
parameters  that  affect  the  Creeping  Line  Ahead  flight  pattern  and  how  to  modify  them. 
The  Creeping  Line  Ahead  manipulation  interface  is  depicted  in  Figure  18. 
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Figure  18.  Creeping  Line  Ahead  Flight  Pattern  Manipulation  Interface 


Table  9.  Creeping  Line  Ahead  Parameters 


PARAMETER  DESCRIPTION  USE 

NAME 


Position 


Assigns  the  geographic  location  of  the  starting 
point  for  the  flight  pattern.  The  position  is 
specified  by  an  x,  y,  and  Altitude  value.  These 
values  are  in  meters. 


The  Start  Point  position  may  be 
selected  interactively  by  clicking  on  a 
location  on  the  MMD  and  then  pressing 
the  Select  button.  Alternatively,  you 
may  select  and  type  discrete  values  into 
the  x,  y  and  Altitude  fields  and  then  hit 
<Enter>  to  apply  the  new  value(s). 


Speed 


Defines  the  speed  at  which  the  simulated  Click  on  the  increment  or  decrement 
search  aircraft  will  fly  the  flight  pattern.  controls  on  the  Speed  spin  box  to 

increase  or  decrease  the  speed  of  the 
simulated  search  aircraft. 
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s 


Represents  the  separation  between  the  flight  legs 
that  make  up  the  pattern.  S  is  measured  in 
kilometres. 


Click  on  the  increment  or  decrement 
controls  on  the  S  spin  box  to  increase 
or  decrease  the  leg  separation.  This 
value  should  be  at  least  0.1  km. 


Leg  Length 


Represents  the  length  of  the  flight  legs  that  make 
up  the  pattern.  Leg  Length  is  measured  in 
kilometres. 


Click  on  the  increment  or  decrement 
controls  on  the  Leg  Length  spin  box  to 
increase  or  decrease  the  length  of  the 
flight  legs.This  value  should  be  at  least 
0.1  km. 


#  of  Legs 


Assigns  the  number  of  flight  legs  that  will  make  up  Click  on  the  increment  or  decrement 
the  flight  pattern.  controls  on  the  #  of  Legs  spin  box  to 

increase  or  decrease  the  number  of 
legs  that  make  up  the  pattern. 


Figure  19  describes  the  Creeping  Line  Ahead  flight  pattern  and  the  parameters  used  to 
generate  it. 


S 

(Leg  Separation) 


\ 

/ 


/ 


Figure  19.  Creeping  Line  Ahead  Parameters 

h.  Expanding  Square  Flight  Pattern 

The  “Expanding  Square”  is  another  commonly  used  search  pattern.  It  is  made  up  of  a 
pattern  of  progressively  larger  squares  (a  "square  spiral").  The  “Expanding  Square” 
flight  pattern  is  a  more  specialized  search  pattern  employed  when  the  general  location  of 
the  object  or  person  being  searched  for  is  known  and  the  search  crew  wishes  to 
concentrate  around  that  area.  An  “Expanding  Square”  flight  pattern  is  depicted  in  Figure 
20.  By  providing  some  elementary  parameter  values,  the  SGE  will  automatically  generate 
a  sequence  of  waypoints  for  you. 

i.  Creating  an  Expanding  Square  Flight  Pattern 

To  create  an  Expanding  Square  flight  pattern: 
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1.  In  the  tabbed  area  select  Aircraft  then  select  the  Expanding  Square  tab. 
The  Expanding  Square  flight  path  manipulation  area  will  be  displayed. 

2.  In  the  Start  Point  area,  designate  the  start  point  for  the  pattern  by  clicking 
a  location  on  the  MMD  and  then  pressing  the  Select  button.  The 
Expanding  Square  flight  pattern  will  be  displayed  on  the  MMD 
configured  with  default  parameter  values. 


Figure  20.  Expanding  Square  Search  Pattern 


j.  Modifying  the  Expanding  Square  Flight  Pattern 

The  Expanding  Square  flight  pattern  is  created  based  on  a  number  of  parameters. 
Changing  these  parameters  will  affect  the  geographic  area  that  the  pattern  will  cover  and 
the  rate  at  which  the  area  is  covered.  The  following  table  describes  the  various 
parameters  that  affect  the  Expanding  Square  flight  pattern  and  how  to  modify  them.  The 
Expanding  Square  manipulation  interface  is  depicted  in  Figure  21. 
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Figure  21.  Expanding  Square  Flight  Pattern  Manipulation  Interface 


Table  10.  Expanding  Square  Parameters 

PARAMETER  DESCRIPTION 
NAME 


USE 


Position 


Assigns  the  geographic  location  of  the  starting  point  The  Start  Point  position  may  be 


for  the  flight  pattern, 
x,  y,  and  Altitude 
meters. 


The  position  is  specified  by  an 
value.  These  values  are  in 


selected  interactively  by  clicking  the 
Select  button  and  then  clicking  on  a 
location  on  the  MMD.  Alternatively,  you 
may  select  and  type  discrete  values  into 
the  x,  y  and  Altitude  fields  and  then  hit 
<Enter>  to  apply  the  new  value(s). 


Speed 


Defines  the  speed  at  which  the  simulated  search 
aircraft  will  fly  the  flight  pattern. 


Click  on  the  increment  or  decrement 
controls  on  the  Speed  spin  box  to 
increase  or  decrease  the  speed  of  the 
simulated  search  aircraft. 


S  Represents  the  separation  between  the  flight  legs  Click  on  the  increment  or  decrement 

that  make  up  the  pattern.  S  is  measured  in  controls  on  the  S  spin  box  to  increase 
kilometres.  or  decrease  the  leg  separation.  This 

value  should  be  at  least  0.1  km. 

#  of  Legs  Assigns  the  number  of  flight  legs  that  will  make  up  Click  on  the  increment  or  decrement 

the  flight  pattern.  controls  on  the  #  of  Legs  spin  box  to 

increase  or  decrease  the  number  of 
legs  that  make  up  the  pattern. 


Direction 


Dictates  the  direction  of  the  first  turn  that  is  made  in 
the  pattern.  The  direction  may  be  clockwise  or 
counter-clockwise. 


Select  the  desired 
Direction  pick-list. 


direction  from  the 
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Figure  19  describes  the  Expanding  Square  flight  pattern  and  the  parameters  used  to 
generate  it. 


Figure  19.  Expanding  Square  Parameters 

k.  Saving  a  Flight  Plan 

Whenever  you  make  changes  to  your  flight  plan  you  will  want  to  preserve  those  changes 
by  saving  the  flight  plan.  To  save  the  flight  plan,  select  File  |  Save  Flight  Plan  on  the 
SGE  window  menu  bar.  Use  the  file  browser  to  navigate  to  the  desired  directory  click 
OK  to  save  the  flight  plan.  Alternatively  you  may  wish  to  overwrite  an  existing  flight 
plan  file.  In  this  case  use  the  file  browser  to  navigate  to  the  directory  that  contains  the  file 
that  you  wish  to  overwrite  and  click  OK. 

5.  Manipulating  Sensors 

At  the  core  of  the  AIMSsim  are  two  electro-optical  sensors:  an  AGTV  and  a  FLIR.  The 
SGE  allows  you  to  control  a  number  of  sensor  parameters.  These  parameters  affect  the 
way  the  simulated  sensors  will  operate,  as  well  as  the  way  in  which  they  will  be  presented 
in  the  HMI  Prototype.  The  sensor  manipulation  interface  is  presented  in  Figure  22. 
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Figure  22.  Sensor  Manipulation  Interface 

The  following  table  describes  the  various  sensor  parameters  and  how  to  modify  them. 
Field  of  view  is  referred  to  as  the  FOV. 


Table  1 1.  Sensor  Parameters 


PARAMETER 

NAME 

DESCRIPTION 

USE 

Sensor  Window 
Configuration 

Controls  the  layout  of  the  sensor  video 
presentation  in  the  HMI  Prototype.  Valid 
settings  are  “Both  Equal",  “AGTV  Primary”, 
“FUR  Primary",  “AGTV  Only”  AND  “FUR  Only”. 
Currently,  “Both  Equal”  uses  two  640x480 
screen  areas  for  the  sensor  display.  The  only 
and  Primary  modes  use  a  larger  4:3  section  of 
the  screen  for  the  primary  sensor  (768x576). 

Select  the  desired  sensor  window 
configuration  from  the  Sensor  Window 
Configuration  pick-list. 

Slave  Sensor 

FOV 

“Slaves”  the  FUR  sensor  FOV  to  that  defined 
for  the  AGTV.  ie.  the  FOV’s  for  both  are  the 
same,  only  one  control  needed  to  zoom  in/out. 

Click  on  the  Slave  Sensor  FOV  radio 
button  to  toggle  the  FOV  slave  setting. 

AGTV  Min 

Assigns  the  minimum  allowable  AGTV  FOV 
that  may  be  achieved  in  the  HMI  Prototype. 

Click  on  the  increment  or  decrement 
controls  of  the  Min  spin  box  to  increase 
or  decrease  the  minimum  sensor  FOV. 

AGTV  Max 

Assigns  the  maximum  allowable  AGTV  FOV 
that  may  be  achieved  in  the  HMI  Prototype. 

Click  on  the  increment  or  decrement 
controls  of  the  Max  spin  box  to  increase 
or  decrease  the  maximum  sensor  FOV. 

DRDC  Atlantic  CR  2006-280 


59 


AGTV  Continuous 

Defines  the  zoom  control  for  the  AGTV  (in  the 
HMI  Prototype)  to  be  a  continuous  range 
between  the  AGTV  Minimum  FOV  and  the 
AGTV  Maximum  FOV. 

Click  on  the  Continuous  radio  button  to 
toggle  the  FOV  setting  between 
“Continuous”  and  “Discrete”. 

AGTV  Discrete 

Defines  the  zoom  control  for  the  AGTV  (in  the 
HMI  Prototype)  to  be  a  discrete  setting.  This 
discrete  setting  may  be  selected  at  runtime  by 
the  HMI  Prototype  operator  to  be  the  AGTV 
Minimum  FOV  or  the  AGTV  Maximum  FOV. 

Click  on  the  Discrete  radio  button  to 
toggle  the  FOV  setting  between 
“Continuous”  and  “Discrete”. 

FUR  Min 

Assigns  the  minimum  allowable  FUR  FOV  that 
may  be  achieved  in  the  HMI  Prototype. 

Click  on  the  increment  or  decrement 
controls  of  the  Min  spin  box  to  increase 
or  decrease  the  minimum  sensor  FOV. 
This  control  has  no  effect  when  Slave 
Sensor  FOV  is  selected. 

FUR  Max 

Assigns  the  maximum  allowable  FLIR  FOV  that 
may  be  achieved  in  the  HMI  Prototype. 

Click  on  the  increment  or  decrement 
controls  of  the  Max  spin  box  to  increase 
or  decrease  the  maximum  sensor  FOV. 
This  control  has  no  effect  when  Slave 
Sensor  FOV  is  selected. 

FUR  Continuous 

Defines  the  zoom  control  for  the  FLIR  (in  the 
HMI  Prototype)  to  be  a  continuous  range 
between  the  FUR  Minimum  FOV  and  the  FUR 
Maximum  FOV. 

Click  on  the  Continuous  radio  button  to 
toggle  the  FOV  setting  between 
“Continuous”  and  “Discrete”.  This 

control  has  no  effect  when  Slave 
Sensor  FOV  is  selected. 

FUR  Discrete 

Defines  the  zoom  control  for  the  FUR  (in  the 
HMI  Prototype)  to  be  a  discrete  setting.  This 
discrete  setting  may  be  selected  at  runtime  by 
the  HMI  Prototype  operator  to  be  the  FLIR 
Minimum  FOV  or  the  FLIR  Maximum  FOV. 

Click  on  the  Discrete  radio  button  to 
toggle  the  FOV  setting  between 
“Continuous”  and  “Discrete”.  This 

control  has  no  effect  when  Slave 
Sensor  FOV  is  selected. 

Simulate  CCD 

Enables/Disables  the  simulation  of  a  CCD 
camera  in  place  of  the  AGTV  sensor 
simulation.  It’s  a  camera  with  no  laser 
illuminator  (essentially  a  normal  camera) 

Click  on  the  Simulate  CCD  radio  button 
to  toggle  the  CCD  simulation  setting 
between  enabled  (lit)  and  disabled 
(unlit). 

Default  Beam 

Width 

Defines  the  default  setting  for  the  simulated 
laser  illuminator  beam  width.  The  operator  may 
override  the  default  setting  at  runtime.  Valid 
beam  widths  are  “Wide”  and  “Narrow”. 

Select  the  desired  default  beam  width 
from  the  Default  Beam  Width  selection 
list. 

Narrow 

Defines  the  size  (in  degrees)  of  the  laser 
illuminator  beam  when  the  AGTV  is  operated  in 
“Narrow”  FOV  mode.  Valid  settings  are  2°  and 
5°. 

Select  the  desired  illuminator  beam  size 
from  the  Narrow  selection  list. 

Wide 

Defines  the  size  (in  degrees)  of  the  laser 
illuminator  beam  when  the  AGTV  is  operated  in 
“Wide”  FOV  mode.  Valid  settings  are  10°,  15°, 
25°, 30°  and  35°. 

Select  the  desired  illuminator  beam  size 
from  the  Wide  selection  list. 

a.  Saving  the  Sensor  Configuration 

Whenever  you  make  changes  to  your  sensor  configuration  you  will  want  to  preserve  those 
changes  by  saving  the  scenario  configuration  settings.  Unlike  the  target  and  flight  plan 
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parameters;  the  sensor  configuration  is  saved  together  with  the  environmental  settings  and 
the  Scenario  Landscape  definition.  So  keep  in  mind,  when  you  are  saving  the  sensor 
configuration,  you  are  also  saving  those  settings. 

To  save  the  sensor  configuration,  select  File  |  Save  Config  on  the  SGE  window  menu  bar. 
Use  the  file  browser  to  navigate  to  the  desired  directory  and  click  OK  to  save  the 
configuration.  Alternatively  you  may  wish  to  overwrite  an  existing  configuration  file.  In 
this  case  use  the  file  browser  to  navigate  to  the  directory  that  contains  the  file  that  you 
wish  to  overwrite  and  click  OK 

6.  Manipulating  the  Map 

The  SGE  allows  you  to  control  various  HMI  map  options.  The  moving  map  is  located  in 
the  upper  right  quadrant  of  the  screen.  When  selecting  a  map  mode  this  involves  8  options 
which  include  both  2D  and  3D  maps: 

1)  No  map. 

The  Map  portion  of  the  HMI  is  blank. 

2)  2D  Paper 

A  correlated  paper  map  image.  This  option  requires  that  a  papermap  be 
available  for  the  area  in  the  terrain  database.  (Nerepis  Only) 

3)  2D  Terrain 

A  2D  moving  map  created  using  a  bird's  eye  view  of  the  terrain  database.  This 
is  available  for  all  databases. 

4)  2D  Shaded 

An  elevation  shaded  representation  of  the  terrain.  This  requires  a  special 
correlated  database.  (Nerepis  Only) 

5)  Immersed 

3D  view  of  the  database  from  the  sensor  position.  A  blue  “ghost-ball”  is  used  to 
indicate  the  users  field-of-view. 

6)  Immersed  Shaded 

Same  as  Immersed,  using  the  elevation  shaded  map. 

7)  Tethered 

3D  view  of  the  database  from  slightly  above  and  behind  the  sensor  position.  A 
blue  “ghost-ball”  is  used  to  indicate  the  users  field-of-view.  A  3D  model  is 
used  to  represent  the  search  aircraft. 

8)  Tethered  Shaded 

Same  as  Tethered,  using  the  elevation  shaded  map. 

Another  option  in  manipulating  the  map  allows  for  adjusting  parameters.  A  scale  can  be 
selected  from  a  range  of  1000  to  250  000.  A  map  scale  will  appear  on  the  2D  map  views 
for  certain  values.  The  ratios  of  1:  1000,  10000,  25000,  50000,  100  000,  125  000,  200 
000,  and  250  000  will  have  a  scale  shown.  Furthermore,  3  options  are  available  for  map 
orientation:  1)  North  Up  (map  is  always  oriented  North  regardless  of  the  flight),  2) 
Aircraft  Up  (map  orients  according  to  aircraft  position  during  flight),  and  3)  Camera  Up 
(map  orients  according  to  camera  position). 

There  are  4  options  available  for  the  aircraft  symbol  on  the  moving  map:  1)  Rotary  Wing 
(simple  helicopter-like  icon),  2)  Fixed  Wing  (simple  aircraft-like  icon),  3)  Pointer  (simple 
circle  with  an  indicator,  which  points  in  the  direction  the  search),  and  4)  There  is  also  an 
option  for  no  icon. 


DRDC  Atlantic  CR  2006-280 


61 


This  section  also  provides  a  function  for  colour  or  greyscale.  Search  history  can  be 
enabled  (selection  of  function  on/function  off).  The  search  history  marks  a  blue  trail  on 
the  map,  of  the  user’s  search.  A  Marking  Function  is  also  an  option  that  can  be  enabled 
(selection  of  function  on/function  off).  The  marking  function  will  show  a  numbered  box 
on  the  map  in  the  position  of  the  designation  when  a  2D  map  is  displayed  in  the  MMD. 
Designations  are  number  in  chronological  order.  A  white  dot  appears  on  the  map  in  the 
position  of  the  designation  when  a  3D  map  is  displayed  in  the  MMD. 

7.  Manipulating  the  Environment 

The  SGE  allows  you  to  control  various  simulated  environmental  parameters.  These 
parameters  will  impact  on  the  effectiveness  of  the  simulated  sensors  in  the  FIMI 
Prototype. 

The  following  table  describes  the  various  environment  parameters  and  how  to  modify 
them. 


Table  12.  Environment  Parameters 


PARAMETER 

NAME 

DESCRIPTION 

USE 

Time  of  Day 
(TOD) 

Controls  the  amount  of  ambient  light 
illuminating  the  AGTV.  Time  of  Day  is 
measured  on  a  scale  from  0.0  to  1.0.  A  value 
of  0.0  represents  complete  darkness  while  a 
value  of  1.0  represents  maximum  illumination. 

Select  the  desired  TOD  setting  by 
positioning  the  Time  of  Day  slider. 
Alternatively,  you  may  increment  or 
decrement  the  TOD  via  the  Time  of 
Day  spin  box. 

Visibility 

Defines  the  visibility  setting  for  the  experimental 
scenario.  Valid  selections  are  “Clear”  and 
“Degraded”. 

Select  the  desired  visibility  setting  via 
the  Visibility  pick-list. 

AG  TV  Effect 

Determines  the  amount  of  degradation  in  the 
AGTV  sensor.  Selecting  the  setting  “1”  will 
result  in  complete  degradation,  selecting  the 
setting  “0”  results  in  no  degradation.  (For 
example,  the  effect  introduces  noise.) 

Click  on  the  increment  or  decrement 
controls  of  the  AGTV  Effect  spin  box  to 
increase  or  decrease  the  amount  of 
degradation  of  the  simulated  AGTV 
sensor. 

FUR  Effect 

Determines  the  amount  of  degradation  in  the 
FUR  sensor.  Selecting  the  setting  “1”  will  result 
in  complete  degradation,  selecting  the  setting 
“0”  results  in  no  degradation.  (For  example,  the 
effect  introduces  noise.) 

Click  on  the  increment  or  decrement 
controls  of  the  FLIR  Effect  spin  box  to 
increase  or  decrease  the  weather 
effectiveness  of  the  simulated  FUR 

sensor. 

a.  Description  of  the  Degradation  Effect 

Computer  images  often  appear  unrealistically  sharp  and  well  defined.  The  degradation 
effect  decreases  this  sharpness  or  the  definition  of  these  images  through  the  addition  of  a 
transparent-noise-screen.  A  percentage  of  degradation  can  be  selected  on  a  scale  of  0  to  1, 
which  will  remain  consistent  throughout  the  scene.  The  selection  of  zero  results  in  no 
degradation,  while  1  is  complete  degradation.  Degradation  is  used  to  better  simulate  real 
world  conditions. 
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b.  Saving  the  Environment  Configuration 

The  environment  configuration  is  saved  together  with  the  sensor  configuration  and  the 
Scenario  Landscape  information.  For  detailed  information  on  saving  the  environment 
configuration,  please  refer  to  Section  a  -  Saving  the  Sensor  Configuration. 

8.  Manipulating  Additional  Scenario  Settings 

The  SGE  allows  to  you  control  additional  scenario  settings.  These  miscellaneous  settings 
control  the  default  configuration  of  the  HMI  Prototype  display  and  of  the  HMI  control 
hardware.  The  miscellaneous  settings  manipulation  interface  is  presented  in  Figure  23. 


Sensor  Scan - 

Scan  Enabled  O 
Scan  Rate  (deg/s)  |lKM  ▼  | 

Scan  Width  (deg)  [io 


-  Joystick - 

Joystick  Mode  |  Aircraft  ▼] 


-  Zoom  Control - 

Zoom  Mode  |  Forward  =  Zoom  In 


-  Memory  Recall - 

Display  Sensors  0  (select  to  enable) 


Figure  23.  Miscellaneous  Settings  Manipulation  Interface 

The  following  table  describes  the  various  miscellaneous  parameters  and  how  to  modify 
them. 


Table  13.  Miscellaneous  Parameters 


PARAMETER 

NAME 

DESCRIPTION 

USE 

Scan  Enabled 

Controls  the  default  state  (enabled/disabled)  of 
the  automatic  sensor  scan  function  in  the  HMI 
Prototype.  When  the  scan  is  enabled,  the 
terrain  is  automatically  scanned  with  no 
movement  of  the  joystick. 

Select  the  default  state  of  the  scan 
function:  enabled  (lit)  or  disabled  (unlit) 
by  clicking  on  the  Scan  Enabled  radio 
button. 
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Scan  Rate 


Scan  Width 


Controls  the  default  scan  rate  of  the  automatic  Select  the  desired  scan  rate  setting 

sensor  scan  function  in  the  HMI  Prototype,  from  the  Scan  Rate  pick-list. 

Valid  scan  rates  are  “1.5  deg/s”,  “3  deg/s”  and 
“6.0  deg/s”. 


Controls  the  width  of  the  default  scan  sweep  by  Select  the  desired  scan  width  setting 
the  automatic  sensor  scan  function  in  the  HMI  from  the  Scan  Width  pick-list. 

Prototype.  Valid  scan  widths  are  “30  deg”,  “60 
deg”  and  “90  deg”. 


Joystick  Mode 


Controls  the  default  manipulation  mode  of  the  Select  the  desired  joystick  mode  setting 

HMI  control  hardware  joystick.  Valid  from  the  Joystick  Mode  pick-list, 

manipulation  modes  are  “Aircraft”  and  “Cursor”. 

When  in  aircraft  mode,  pushing  forward  on  the 
joystick  results  in  the  sensor  turret  pitching 
down  and  pulling  back  on  the  joystick  results  in 
the  sensor  turret  pitching  up.  When  in  cursor 
mode,  the  pitch  control  relationship  is  reversed: 
pushing  forward  on  the  joystick  results  in  the 
sensor  turret  pitching  up  and  pulling  back  on 
the  joystick  results  in  the  sensor  turret  pitching 
down. 


Zoom 

Mode 


Control  Controls  the  default  manipulation  mode  of  the 
HMI  control  hardware  zoom  levers.  Valid 
manipulation  modes  are  “Forward  =  Zoom  In” 
and  “Forward  =  Zoom  Out”.  When  in  “Forward 
=  Zoom  In”  mode,  pushing  forward  on  the  zoom 
lever  results  in  the  sensor  zooming  in  and 
pulling  back  on  the  zoom  lever  results  in  the 
sensor  zooming  out.  When  in  “Forward  = 
Zoom  Out”  mode,  the  zoom  control  relationship 
is  reversed:  pushing  forward  on  the  zoom  lever 
results  in  the  sensor  zooming  out  and  pulling 
back  on  the  zoom  lever  results  in  the  sensor 
zooming  in. 


Select  the  desired  zoom  control  mode 
setting  from  the  Zoom  Control  Mode 
pick-list. 


Display  Sensors  Allows  the  Memory  Recall  capability  to  be  If  this  box  is  not  checked,  the  prototype 
enabled.  In  this  mode,  no  sensor  imagery  will  will  run  in  Memory  Recall  mode, 
be  displayed. 


9.  Altitude  Profile  Display 

The  Altitude  Profile  Display  provides  a  graphical  representation  of  the  simulated  search 
aircraft  altitude  profile  and  terrain  elevation  profile  with  respect  to  the  scenario  timeline. 
The  data  points  that  create  the  aircraft  altitude  profile  are  a  result  of  the  waypoints  defined 
in  the  flight  plan.  As  such,  the  numbers  represented  on  the  altitude  profile  correspond  to 
waypoint  numbers  in  the  flight  plan.  The  aircraft  altitude  profile  is  drawn  in  blue  and  the 
terrain  elevation  profile  is  drawn  in  green.  The  altitude  profile  display  is  presented  in 
Figure  24. 
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Figure  24.  Altitude  Profile  Display 


10.  The  Scenario  Summary  Area 

The  Scenario  Summary  Area  provides  summary  information  about  the  AIMSsim 
experimental  scenario  that  you  have  created.  The  summary  information  includes  an 
estimated  time  for  executing  the  scenario  as  well  as  information  about  the  total  number  of 
targets  and  non-targets  defined  in  the  scenario. 

11.  Managing  Your  Projects 

A  project  is  a  logical  means  of  grouping  target  information,  flight  plan  information  and 
HMI  configuration  information  (including  sensor,  environment  and  scenario  landscape 
information)  to  form  a  complete  experimental  scenario. 

a.  Saving  Your  Project 

Once  you  have  defined  these  elements  of  scenario  information,  you  may  preserve  the 
logical  grouping  by  saving  your  project.  To  save  a  project,  select  File  |  Save  Project  on 
the  SGE  window  menu  bar.  Use  the  file  browser  to  navigate  to  the  desired  directory  and 
click  OK  to  save  the  project.  This  will  create  four  files  in  the  selected  directory  which 
will  store  all  of  the  information  for  the  current  project  (i.e.  ‘project.xmT,  ‘flightplan.xmT, 
‘config.xml’  and  ‘targets. xml).  Alternatively  you  may  wish  to  overwrite  an  existing 
project.  In  this  case  use  the  file  browser  to  navigate  to  the  directory  that  contains  the 
project  files  that  you  wish  to  overwrite  and  click  OK. 

b.  Loading  an  Existing  Project 

To  load  an  existing  project,  select  File  |  Open  Project  on  the  SGE  window  menu  bar. 
Use  the  file  browser  to  navigate  to  the  directory  than  contains  the  existing  project  files 
and  select  the  ‘project.xmT  file  -  click  OK.  The  SGE  will  load  the  project  parameters 
contained  in  these  files. 

E.6  Viewing  a  Specific  Target  Object 

In  previous  sections  explaining  the  use  of  the  AIMSsim  SGE,  mention  was  made  of  a 
Target  view  mode.  This  mode  is  toggled  from  within  the  SGE  to  view  the  placement 
and  orientation  of  target  objects  in  3D  space  with  respect  to  the  surrounding  terrain. 

E.7  Scenario  Definition  Files 

The  preferred  method  of  creating  Scenario  Definition  files  is  via  the  AIMSsim  SGE. 
This  is  particularly  true  with  regard  to  the  current  version  of  the  SGE  as  the  file  format 
has  been  changed  from  plain  ASCII  text  files  to  XML  encoded  files.  The  content  of 
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these  files  is  still  viewable  using  a  simple  text  editor.  Since  two  of  the  files  that  are 
generated  by  the  SGE  (flightplan.xml  and  targets. xml)  can  be  read  natively  by  the 
AIMSsim  HMI,  only  the  SGE  configuration  file  (config.xml)  will  be  discussed  here. 

In  addition,  a  description  of  the  target  mapping  file  will  also  be  presented.  It  is  not 
recommended  that  any  of  these  files  be  edited  outside  of  the  SGE  as  this  may  cause 
improper  functioning. 

1.  Configuration  File 

The  Configuration  file  contains  information  about  the  Scenario  Landscape,  the 
configuration  of  the  simulated  sensors  and  the  configuration  of  the  HMI  Prototype.  It  is 
divided  in  five  main  sections  each  delimited  by  an  XML  tag  set.  An  example  of  the  SGE 
configuration  file  is  given  below. 

<config> 

<terrain>c:\AimsDB/terrains/Nerepis/ELVISS_ne.ive</terrain> 

<environment> 

<tod>1</tod> 

<vis>0</vis> 

<agtv_effect>1  </agtv_effect> 

<f  I  i  r_eff e  ct  >  2  < /f  I  i  r_effect> 

</environment> 

<sensor> 

<win_cfg>0</win_cfg> 

<slaved>0</slaved> 

<agtv_fov_min>0.5</agtv_fov_min> 

<agtv_fov_max>40</agtv_fov_max> 

<agtv_mode>0</agtv_mode> 

<agtv_beam_width>0</agtv_beam_width> 

<agtv_sim_ccd>0</agtv_sim_ccd> 

<agtv_narrow_size>0</agtv_narrow_size> 

<agtv_wide_size>0</agtv_wide_size> 

<f  I  i  r_f o  v_m  i  n  >  0 . 5</f  I  i  r _fo  v_m  i  n  > 

<fl  ir_fov_max>40</flir_fov_max> 

<flir_mode>1</flir_mode> 

</sensor> 

<misc> 

<scan_rate>0</scan_rate> 

<scan_width>0</scan_width> 

<scan_enable>0</scan_enable> 

<joy_mode>0</joy_mode> 
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<zoom_mode>0</zoom_mode> 

</misc> 

<map> 

<mode>0</mode> 

<scale>50000</scale> 

<orient>0</orient> 

<symbol>0</symbol> 

<colour>0</colour> 

<search_history>0</search_history> 

<mark_function>0</mark_function> 

<recall_sensor>0</recall_sensor> 

<fov>60</fov> 

<slave_fov>0</slave_fov> 

</map> 

</config> 


The  entire  configuration  file  is  enclosed  within  the  <config>,  </config>  tag  set.  The  five 
major  sections  fall  within  this  global  set.  The  first  major  section  of  the  configuration  file 
occurs  within  the  <terrain>  tag.  The  value  contained  in  this  tag  represents  an  absolute 
path  to  the  location  of  the  terrain  file  being  used  with  the  current  scenario.  The  four  other 
sections  (sensor,  environment,  map  and  misc)  are  delimited  by  XML  tags  similarly 
named.  These  four  sections  correspond  to  the  latter  four  tabs  that  occur  in  the  SGE  GUI. 
Each  of  these  sections  contains  properties  that  can  be  both  viewed  and  set  from  the 
appropriate  tab  in  the  SGE  GUI.  A  description  of  these  properties  now  follows. 


Table  14.  Configuration  File  Specification 

XML  TAGS  DESCRIPTION  VALUE 

<terrain>  The  absolute  file  path  to  the  terrain  A  valid  file  path, 

database  file. 

<environment>  The  second  major  section  of  the  N/A 

configuration  file  which  contains  all 
environment  settings. 

<tod>,</tod>  The  Time  of  Day  (TOD)  to  be  represented  0.0-  1.0 

in  the  HMI  Prototype. 


<vis>,</vis> 

The  weather  condition  to  be  represented  in 
the  HMI  Prototype. 

0  =  Clear 

1  =  Degraded 

<agtv_effect>, 

</agtv_effect> 

The  capability  of  the  simulated  AGTV 
sensor  to  penetrate  the  fog. 

O 

1 

q 

o 

<flir_effect>, 

</flir_effect> 

The  capability  of  the  simulated  FLIR  sensor 
to  penetrate  the  fog. 

q 

1 

q 

o 
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<sensor> 


The  third  major  section  of  the  configuration  N/A 
file  which  contains  all  of  the  sensor 
settings. 


<win_cfg>,  </win_cfg>  An  integer  value  that  controls  the  layout  of  0  =  Both  Equal 

the  sensor  video  presentation  in  the  HMI  1  =  AGTV  Primary 
Prototype.  2  =  FUR  Primary 

3  =  AGTV  Only 

4  =  FUR  Only 

<slaved>,  </slaved>  A  flag  that,  when  set,  “Slaves”  the  FUR  0  =  not  slaved 
sensor  FOV  to  that  defined  for  the  AGTV.  1  =  slaved 


<agtv_fov_min>, 

</agtv_fov_min> 

A  single  precision  floating  point  value  that 
assigns  the  minimum  allowable  AGTV  FOV 
that  may  be  achieved  in  the  HMI  Prototype. 
Measured  in  degrees. 

0.5-40.0 

<agtv_fov_max>, 

</agtv_fov_max> 

A  single  precision  floating  point  value  that 
assigns  the  maximum  allowable  AGTV 
FOV  that  may  be  achieved  in  the  HMI 
Prototype.  Measured  in  degrees. 

0.5-40.0 

<agtv_m°de>, 

</agtv_mode> 

An  integer  value  that  controls  the  zoom 
control  for  the  AGTV. 

0  =  Continuous 

1  =  Discrete 

<agtv_beam_width>, 

</agtv_beam_width> 

An  integer  value  that  defines  the  default 
width  of  the  illuminator  beam. 

0  =  Wide 

1  =  Narrow 

<agtv_sim_ccd>, 

</agtv_sim_ccd> 

An  integer  value  that  defines  the  state  of 
CCD  simulation. 

0  =  Do  not  simulate  CCD 

1  =  Simulate  CCD 

<agtv_narrow_size>, 

</agtv_narrow_size> 

An  integer  value  that  defines  the  size  (in 
degrees)  of  the  AGTV  laser  illuminator 
beam  when  operating  in  “Narrow”  FOV 
mode. 

0  =  2  deg 

1  =  5  deg 

<agtv_wide_size>, 

</agtv_wide_size> 

An  integer  value  that  defines  the  size  (in 
degrees)  of  the  AGTV  laser  illuminator 
beam  when  operating  in  “Wide”  FOV 
mode. 

0  =  10  deg 

1  =  15  deg 

2  =  20  deg 

3  =  25  deg 

4  =  35  deg 

<flir_fov_min>, 

</flir_fov_min> 

A  single  precision  floating  point  value  that 
assigns  the  minimum  allowable  FUR  FOV 
that  may  be  achieved  in  the  HMI  Prototype. 
Measured  in  degrees. 

0.5-40.0 

<flir_fov_max>, 

</flir_fov_max> 

A  single  precision  floating  point  value  that 
assigns  the  maximum  allowable  FUR  FOV 
that  may  be  achieved  in  the  HMI  Prototype. 
Measured  in  degrees. 

0.5-40.0 

<flir_mode>, 

</flir_mode> 

An  integer  value  that  controls  the  zoom 
control  for  the  FUR. 

0  =  Continuous 

1  =  Discrete 

<agtv_sim_ccd>, 

</agtv_sim_ccd> 

Enables/Disables  the  simulation  of  a  CCD 
camera  in  place  of  the  AGTV  sensor 
simulation. 

Select  to  enable  (0=inactive,  1=active) 
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<map> 

The  fourth  major  section  of  the 
configuration  file  which  contains  all 
properties  pertaining  to  the  map. 

N/A 

<mode>,  </mode> 

Defines  the  map  (upper  right  quadrant)  for 
the  scenario.  Valid  map  selections  are  “No 
Map”,  “2D  Paper”,  “2D  Terrain",  “2D 
Shaded”,  “Immersed”,  “Immersed  Shaded”, 
“Tethered”  and  “Tethered  Shaded” 

Select  the  desired  map  mode  setting 
from  the  Map  Mode  pick-list 

<scale>,  </scale> 

Controls  the  default  orientation  setting  for 
the  HMI  Prototype  MMD.  Valid  map  scales 
range  from  1:1  to  1:250,000. 

Select  the  desired  map  scale  using 
either  scale  bar  selection,  or  manual 
entry. 

<orient>,  </orient> 

Defines  the  default  orientation  setting  for 
the  HMI  prototype  MMD.  Valid  map 
orientations  are  “North  Up",  “Aircraft  Up”, 
and  “Camera  Up". 

Select  the  desired  map  orientation 
setting  from  the  Map  Orientation  pick- 
list 

<symbol>,  </symbol> 

Controls  the  default  symbol  used  to 
represent  the  position  and  orientation  of 
the  simulated  search  aircraft  for  the  HMI 
Prototype  MMD.  Valid  aircraft  symbols  are 
“Rotary  Wing”,  “Fixed  Wing”,  “Pointer”  and 
“No  Icon”. 

Select  the  desired  aircraft  symbol 
setting  from  the  Aircraft  Symbol  pick-list 

<colour>,  </colour> 

Defines  the  colour  of  the  terrain  as  either 
colour  or  greyscale. 

Select  the  desired  colour  setting  from 
the  Colour  Mode  pick-  list. 

<search_history>, 

</search_history> 

Enables  a  function  where  blue  markings 
reveal  past,  or  most  recent  search  on 
MMD. 

Select  to  enable  (0=inactive,  1=active) 

<mark_function>, 

</mark_function> 

Enables  the  designated  function. 

Select  to  enable  (0=inactive,  1=active) 

<fov>,  </fov> 

Represents  the  Map  field  of  view. 

Select  a  value  from  1-120  deg. 

<slave_fov>, 

</slave_fov> 

Enabled  only  when  MMD  is  “Immersed”  or 
“Tethered”.  It  is  similar  to  having  an 
additional  sensor,  which  allows  for  zoom. 

Select  to  enable  (0=inactive,  1=active) 

<misc> 

The  fifth  section  of  the  configuration  file 
which  contains  miscellaneous  settings. 

N/A 

<scan_enable>, 

</scan_enable> 

An  integer  value  that  controls  the  default 
scan  state  setting. 

Select  to  enable  (0=inactive,  1=active) 

<scan_rate>, 

</scan_rate> 

An  integer  value  that  controls  the  default 
scan  rate  setting. 

0  =  1.5  deg/s 

1  =  3.0  deg/s 

2  =  6.0  deg/s 

<scan_width>, 

</scan_width> 

An  integer  value  that  controls  the  default 
scan  sweep  width  setting. 

0  =  30  deg 

1  =  60  deg 

2  =  90  deg 

<joy_mode>, 

</joy_mode> 

An  integer  value  that  controls  the  default 
joystick  mode  setting. 

0  =  aircraft  mode 

1  =  cursor  mode 
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<zoom_mode>,  An  integer  value  that  controls  the  default  0  =  Forward-Zoom  In 

</zoom_mode>  zoom  mode  setting.  1  =  Forward-Zoom  Out 

<recall_sensor>,  Permission  for  sensors  to  be  activated  (not  Select  to  enable  (0=inactive,  1=active) 

</recall_sensor>  a  default  function). 


2.  Target  Mapping  File 

The  Target  Mapping  file  relates  a  “descriptive”  name  to  a  3D  model  file  name.  This 
approach  was  used  in  order  to  provide  a  meaningful  name  to  the  SGE  user,  while 
maintaining  the  capability  to  represent  an  appropriate  3D  model  in  the  HMI  Prototype. 

The  Target  Mapping  file  contains  two  columns  of  alpha-numeric  data.  The  first  column 
contains  the  descriptive  name  of  the  object,  while  the  second  column  contains  the  file 
name  of  the  3D  model. 

Both  the  SGE  and  the  EIMI  Prototype  read  the  contents  of  the  Target  Mapping  file  at 
runtime.  As  such,  you  may  add  additional  targets  to  the  Target  Mapping  file  by  following 
the  simple  two-column  format.  The  target  Type  field  present  in  the  Target  Definition  file 
utilizes  a  numerical  index  into  the  Target  Mapping  file.  For  this  reason  it  is 
recommended  that  any  new  entries  be  appended  to  the  end  of  the  file  so  as  not  to 
invalidate  any  scenarios  that  were  developed  prior  to  your  modifications. 

The  current  target  mapping  file  in  the  database  is  called  target  map .  txt. 
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